Using multithreading in the Java plug-in server
In previous releases, the Java plug-in server created a thread to handle each RPC connection as it was received from the AR System server, often creating many threads. If a connection failed, the plug-in server programmatically shut down the plug-in instances associated with the thread for that connection, often losing data in the process.
To improve performance, the Java plug-in server now uses a configurable pool of worker threads to handle RPC calls. The pool and its associated plug-in instances are created at startup, rather than as RPC calls are received. If a connection fails, the plug-in instances associated with the thread remain instantiated and can still process calls from other connections.
Do not send any requests to the Java plug-in server before the plug-ins are loaded and instantiated. (If the plug-in log level is Warn or higher, a message is recorded in the log file when the plug-in server is ready to receive RPC calls.)
When an RPC call is received from the AR Server, a selector thread adds the call to the worker thread task queue. By default, the system uses two selector threads. To prevent bottlenecks, you can increase the number of selector threads by using the
Whenever a worker thread is free, it starts processing the next request in the task queue. By default, the pool contains five worker threads. To prevent bottlenecks, you can increase the number of worker threads by using the
An unlimited number of tasks can be added to the worker thread task queue. To be notified when too many tasks accumulate in the queue, you can specify a task threshold. When the threshold is exceeded, a message is logged in the arjavaplugin.log file. This enables you to avoid potential queue bottlenecks by creating more worker threads in a timely fashion.
To specify the task threshold, use the
To specify how frequently the system checks to see whether the task threshold has been exceeded, use the Work Queue Monitor Log Interval