Iotellect Server Runtime Problems

This section covers different runtime errors that may be diagnosed using Iotellect Server logging facility or system events.

Our new partners and customers often complain that Iotellect Server may fail in case of misconfiguration and wonder why the configuration isn't validated for "fool tolerance". However, the lack of platform-level data validation is an explicit strategy of platform development.

Iotellect is a low-code development toolset, so it must be extremely flexible to cover any possible application scenario. However, a platform configuration that will perfectly fit one use case will lead to system failure in another use case.

For example, if we configure the database device driver to synchronize its variable backed by a complicated SQL query with a 10 milliseconds period, Iotellect Server will likely fail trying to execute a hundred "heavy" queries per second. However, we cannot limit the minimal synchronization period to one second (as sometimes requested by users) because, for example, it's quite typical for the Modbus device driver to read PLC registers every several milliseconds. Moreover, even the same database device driver can read variables backed by simple queries once per several hundred milliseconds!

In another example, inexperienced users may set the model's thread pool size to several thousand threads once they're configuring a resource-constrained edge instance of the server. This will certainly cause the server's failure to service any requests. However, we cannot limit pool size to, let's say, a hundred threads since large 128-core servers operating as a heart of a situation center may run models with ten thousand threads.

This lack of failure protection concept may be familiarised by matching it to developing new software using classing programming languages. For example, you can write inefficient or erroneous Java code that will fail, eat up CPU/RAM/HDD space, and even affect other applications running on the same host. However, the Java development platform itself doesn't prevent you from writing such code, it's the software architect's job to do things in the right way.

Similarly, Iotellect application architects should take care of matching Iotellect Server configuration to specific execution environments and resources. In addition, they are normally taking care of implementing data validation inside platform-based services and products, protecting end users and system operators from crashing the system in case of a simple data entry mistake.

Please check the Dealing with Memory Usage section to figure out how Iotellect Server memory usage is configured and how it should be interpreted.

This message means that the operating system does not allow Java Virtual Machine to create a new thread. There are several solutions to this problem:

• If your server uses models or widgets running in the server VM, decrease the number of parallel bindings used by them.

• Decrease maximum memory available to JVM (JVM heap size). This increases the memory available for individual threads.

• Decrease thread stack size.

• Switch to a 64-bit operating system and Java virtual machine.

This error means that your Java Virtual Machine has run out of memory. The solution is to increase the maximum memory available to JVM.

This error indicates that your Java virtual machine is running out of memory to store loaded classes. In this case, you should increase the value of the -XX:MaxPermSize parameter in the server loader parameters.

This situation occurs when Iotellect Server opens a large number of sockets while communicating with networked devices (e.g. via SNMP protocol).

To solve this issue, add the following line to the beginning of Iotellect Server startup scripts (iot_server, %LS_BINARY%_console and %LS_BINARY%_service):

ulimit -n 100000

This command increases the limit of open files allowed for the Iotellect Server to 100000.

Server startup scripts will be re-created during server upgrade, so this instruction must be re-added once the server was upgraded.

This may happen when Iotellect Server runs in console mode since the Windows command processor doesn't use UTF-8 encoding by default. To enable UTF-8 as the default encoding:

• Open registry editor

• Go to HKEY_LOCAL_MACHINESoftwareMicrosoftCommand ProcessorAutoRun

• Create AutoRun parameter of REG_SZ type if it doesn't exist

• Change the value of the AutoRun parameter to chcp 65001

• Restart Iotellect Server

Iotellect Server inherits the default behavior of Java VM and resolves empty IP addresses and empty host names into localhost (127.0.0.1) loopback address. Thus, if the local machine is capable of accepting a connection on a specified TCP/UDP port, a connection may be successful even with the empty address.

There are a number of situations which can lead to corrupted messages between the WebSocket client and server, including a mismatch between server and client compression extensions. This can sometimes result in an Error connect to WS API, preventing users from logging on to Iotellect via the Web UI. A solution is to disable WebSocket compression in the Iotellect Server. This can be done by adding the following line to the Iotellect Server Launcher Properties file iot_server.vmoptions:

-Dorg.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS=true

Once the iot_server.vmoptions file has been updated, restart the server.

Was this page helpful?

Tell us more

Send

Thank you!