Handling Many Connections on the Client Side
When a client Java application establishes many simultaneous sessions, or nSession instances, to Universal Messaging, you might encounter the following issues:
The client application might run out of memory because the many Java threads that are created consume a lot of memory.
The client application might return the error
"java.net.SocketException: Too many open files" because it has reached the maximum allowed count of open files, or sockets, on the operating system.
Resolve Out of Memory Issues
Each non-multiplex nSession to Universal Messaging creates at least three Java threads:
A connection read thread (
UM-Connection-Reader) - responsible for reading events received from the Universal Messaging server.
A connection write thread (
fProcessThreadedQueue) - responsible for sending events to the Universal Messaging server.
One or more event dispatch threads (
UM-Event-Processing-Pool) - responsible for processing events that are read from the connection. These threads are available only when threading is enabled on the session. Threading is enabled by default and a thread is created when the session is started. For more information about threading, see the Universal Messaging Java API reference documentation for
nSession.enableThreading(boolean).
The Java virtual machine (JVM) allocates a certain amount of memory to each thread stack. For this reason, when many threads are created for many sessions, the client application might run out of memory.
You can perform the following actions to reduce memory consumption:
Reduce the amount of memory allocated for a thread stack by using the
-Xss command-line option of the JVM. For more information about the option, see the documentation of your JVM vendor.
Decrease the number of event dispatch threads used for every session by configuring the
com.softwareag.um.client.useSharedThreadPool and
com.softwareag.um.client.SharedThreadPoolMaxSize client system properties.
Normally, the Universal Messaging Java client uses a dedicated thread pool of event dispatch threads for every session. Instead, you can configure the client to use a single, shared thread pool for this type of threads for all client sessions by using the following properties.
com.softwareag.um.client.useSharedThreadPool - enables usage of a shared thread pool for processing incoming nConsumeEvent events for each client session. Values are
true or
false (default). By default, each client session creates and uses a separate thread pool for processing received nConsumeEvent events. When this system property is set to
true, all client sessions will use a shared thread pool. Using a shared thread pool for all client sessions may have a performance impact depending on the size of the shared thread pool and the number of client sessions.
Note:
When each client session uses a separate thread pool, closing the session interrupts any event listener threads that are blocked during processing. When all client sessions share a thread pool, closing a session does not interrupt any event listener threads that are blocked during processing. Thus, the blocked event listener does not release a shared thread after closing the client session. This behavior impacts the processing of incoming events, because the shared pool will not have available threads. Software AG recommends to enable the shared pool for all client sessions only if the event listener of the client application ensures that the processing of the events is fast and graceful.
com.softwareag.um.client.SharedThreadPoolMaxSize - specifies the maximum size of the shared thread pool. The default is
5 threads.
Resolve Socket Exceptions
The connection protocol used for each session to Universal Messaging impacts the total number of sockets that are created. An nSession using the nsp or nsps protocol, that is, the Universal Messaging socket protocol or SSL socket protocol, uses a single socket for communication with the Universal Messaging server. An nSession using the nhp or nhps protocol, that is, the Universal Messaging HTTP or HTTPS protocol, uses two sockets for communication with the server.
An application creating many sessions might fail with a "java.net.SocketException: Too many open files" error if it creates so many sockets that it reaches the maximum allowed count of open files, or sockets, on the operating system.
To resolve this issue, you might need to perform any or a combination of the following actions:
Increase the limit of maximum allowed files or sockets.
Consider if your application requires that many sessions.
Check if the application creates sessions but fails to close them after they are no longer needed.
Check for TCP/IP port exhaustion.
This issue might occur even when the application closes sessions when they are no longer needed. If the application creates and then closes a lot of sessions in a short time, it might cause TCP/IP port exhaustion because operating systems usually keep sockets in a waiting status (TIME WAIT) for some time after sockets are released by the application. In this case, you might need to do the following:
Expand the range of ports available for use by your application.
Reduce the time the operating system keeps those sockets in a waiting status after they are released.