Iotellect Server Threads and Thread Pools
This appendix lists the most important threads and thread pools used by Iotellect Server. It helps experienced system administrators and module/solution developers to deeply understand internal server status and troubleshoot runtime issues.
Current status and stack traces of all server threads (including ones described here) may be accessed via actions and status variables of Root context (such as All Threads, Thread Pool Statistics and Thread Statistics variables available via View Server Status action).
Thread Name Prefix | Thread and Thread Pool Information |
| Action threads execute server actions. An action thread may either execute server-side action code or be blocked awaiting user's response to a UI procedure. |
| Client command processor thread pool is processing commands of desktop and API clients, namely Get/Set Variable, Call Function and Subscribe/Unsubscribe Event commands. Once a command processing is started, processing thread's name is changed to reflect command details by the following patterns:
|
| Client threads are servicing connections of desktop and API clients. A separate thread is created for every connection. |
| Context operations thread pool is used to speed up concurrent operations of server contexts. It is heavily used during server startup and shutdown. For example, every resource (such as an alert) in a container context is initialized in a separate task that's submitted to context operation executors pool. Thus, checking status of pool threads might be very useful for diagnosing server statup and shutdown performance. |
| Event dispatcher threads retrieve events from event queues and call event listeners that handle them. Thus, checking status of event dispatchers is a good idea if event queue lengths grow or event processing is generally delayed from user perspective. Server's main event dispatcher thread is called |
| This is the name of Iotellect Server main thread. |
| Synchronizer threads are performing device synchronization. They perform device driver calls and bridge data between the driver and device context. State of synchronizer threads should be checked to diagnose device synchronization delays and problems, especially for custom device drivers based on the driver development kit. |
| Threads in this pool are timer threads responsible for starting periodic device synchronization. |
Was this page helpful?