Connections Manipulation 

Use

The management of client connections in the cluster is represented in J2EE Engine by the Connections Manipulator Manager. This manager has an indirect connection with all services running on the dispatcher that receive or send data outside the cluster using a socket. It provides threads in which the processing of the received requests, their transfer from the dispatcher to the server, and the return of the response back to the user is accomplished.

Use this procedure to configure the maximum number of user connections that a dispatcher will be able to process at a certain moment, a timeout for these connections, and the connections checks.

Activities

Configuring the Maximum Number of User Connections

The maximum number of user connections that the dispatcher can handle at a given moment is calculated by the system according to the memory (heap size) allocated to the dispatcher. By default, the Max heap size allocated to a dispatcher node is 170 MB. Thus, after making some allowances for connections reserved for internal communication and assuming that each connection consumes 10 KB memory, by default the maximum number of parallel user connections that a dispatcher (with 170 MB Max heap size) can handle is 12,403. If you change the Max heap size of a dispatcher node, the system will dynamically determine the maximum number of allowed user connections. When this number is exceeded, the users are rejected.

To view or change the Max heap size of a dispatcher node, use the Config Tool.

To check the maximum number of allowed user connections, use Telnet and execute the following commands:

add debug

debugmanager ConnectionsManipulator

The number calculated by the system is displayed as a value of the maxPossibleParallelUsers property.

However, you can limit the maximum number of user connections below the number that the system has calculated. To do so, proceed as follows:

       1.      Start the J2EE Engine Visual Administrator.

       2.      Choose Dispatcher → Kernel → Connections Manipulator → Properties tab.

       3.      Modify the value of the MaxParallelUsers property.

By default the value of this property is 0, which means that the system does not take this property into account and the maximum number of allowed user connections at a given moment is calculated by the system as described above.

When you modify the value of this property, the behavior of the system is as follows:

¡        If your value is bigger than the maximum value the dispatcher can afford, the system will set its maximum value instead of your one.

¡        If your value is less than the maximum value the dispatcher can afford, the system will accept your value.

Note also that when you increase the Max heap size of a dispatcher node and thus the maximum number of allowed user connections, you must also monitor the thread system and the log files and, if necessary, reconfigure the thread system as well (for example, the request/response times are higher that usual or the number of free threads is very small). For more information, see Thread System.

Configuring the Connections Timeout

When the connections need more time to establish the communication between the dispatcher and the client side (for example, new connections in WAN), you need to increase the default connections timeout as it may not be enough and the connections may fail.

We recommend that you estimate carefully the new value that you will assign to the connections timeout property, because setting a too high value might lead to blocking additional resources in the thread system.

To modify the default connections timeout, proceed as follows:

...

       1.      Start the J2EE Engine Visual Administrator.

       2.      Choose Dispatcher → Kernel → Connections Manipulator → Properties tab.

       3.      Modify the value of the GetStreamsSoTimeout property.

For SSL connections, the value of this property is overwritten by the HANDSHAKE_SO_TIMEOUT and the RUNTIME_SO_TIMEOUT properties of the SSL Provider Service on the dispatcher nodes. For more information about these properties, see SSL Provider Service.

Configuring the Connections Checks

The system performs two types of connection checks: an availability check (a check if some data is available to read in the connection) and a close-wait check (a check whether the connection is open or closed on the client side). By configuring these checks, you can change the balance between the CPU load and the overall system performance. You achieve this by modifying the value of the CloseWaitCheckPeriod property.

This property determines the number of availability checks for a connection, after which the system performs a check whether the connection is in close-wait status, that is, if the connection is closed on the client side but is still open on the server side. If the result of this check is positive, the system closes that connection on the server side, too. The default value is 100, that is, after each 100 checks for availability, the system checks whether the connection is in close-wait status.

·        To improve the system performance, increase the value of the CloseWaitCheckPeriod property.

However, if you increase the CloseWaitCheckPeriod value and there are a lot of client connections in close-wait status, then the total number of connections in the connections queue increases. This in turn increases the CPU time needed to process this queue and the system needs more time to detect that a connection is in close-wait status and has to be closed on the server side.

·        To decrease the CPU consumption, decrease the value of the CloseWaitCheckPeriod property.

If you decrease the CloseWaitCheckPeriod value, you increase the frequency in which the system checks if there are connections in close-wait status. This affects negatively the overall performance of all connections but also closes faster the connections in close-wait status and thus decreases the CPU consumption.

The close-wait check is time consuming. Therefore, be careful when decreasing the CloseWaitCheckPeriod value, because although this check does not block the CPU, it blocks the thread that serves the corresponding connection. Thus, if there are a lot of connections and you decrease the property value, this may result in blocking too many threads and, respectively, in a system bottleneck.