Client Engine connectionMax

Client Engine connectionMax

[[Server Engine connectionMaxIdle|Back]]

In the previous articles, you have learnt about the properties which you can tune to control the incoming connections at the Server side ORB. The Client side ORB also has it's own set of properties to control the outgoing connections. In this article, we will touch on the Client Engine "vbroker.ce.iiop.ccm.connectionMax" property.

The "echo_service_cpp" [[Explanation of Example|example]] is used in this demonstration.

Scenario

  • Start 1 Client to call 10 Servers.
  • 2 client threads are created by the Client to call each Server concurrently.
  • Each client thread calls the Server once.
  • Each invocation blocks for 10 seconds at the Server side.
  • Monitor the Client's resource consumption and invocation performance with the default configuration.
  • Observe the effect of setting Client Engine "connectionMax=5".

How many outgoing connections are established by the Client to make invocations to the 10 Servers concurrently?

Preparation

Configure the Client by modifying c.sh:

  • Set the following properties:
    • server_sleep_time 10
    • vbroker.agent.enableLocator=false
  • Disable all the other properties.

Configure the Server by modifying s.sh:

  • Set the following properties:
    • vbroker.agent.enableLocator=false
    • vbroker.se.default.local.manager.enabled=false
  • Disable all the other properties.

Execution

Make sure you have set up the necessary VisiBroker environment and build the example before running this demonstration.

  • Start the Client Monitor script:
    • mon_c.sh
  • Start the 10 Servers:
    • s.sh 10
  • Start the Client:
    • c.sh 1 10 2
  • Monitor the Client's resource consumption (printed by Client Monitor). E.g.:

MEMORY(KB) THREADS SOCKETS
12400      21      10

  • Count the number of successful invocations based on the logs (printed by Client). E.g.:

. . . . . .
Reply of Client Thread Id P18576_T2_S1 is P18576_T2_S1, time taken is 10.0212
Reply of Client Thread Id P18576_T4_S2 is P18576_T4_S2, time taken is 10.0219
Reply of Client Thread Id P18576_T6_S3 is P18576_T6_S3, time taken is 10.0225
Reply of Client Thread Id P18576_T7_S4 is P118576_T7_S4, time taken is 10.0291
. . . . . .

  • Stop the Client and 10 Servers.
  • Set the following property at the Client side by modifying c.sh:

vbroker.ce.iiop.ccm.connectionMax=5

  • Re-start the 10 Servers:
    • s.sh 10
  • Re-start the Client:
    • c.sh 1 10 2
  • Monitor the Client's resource consumption (printed by Client Monitor). E.g.:

MEMORY(KB) THREADS SOCKETS
12392      11      5

  • Count the number of successful invocations based on the logs (printed by Client). E.g.:

. . . . . .
Client Thread Id P18932_T14_S7 caught Exception: CORBA::NO_RESOURCES
Minor: 1330446336
Completion Status: NO
, time taken is 0.041587
Client Thread Id P18932_T12_S6 caught Exception: CORBA::NO_RESOURCES
Minor: 1330446336
Completion Status: NO
, time taken is 0.042078
Reply of Client Thread Id P18932_T1_S1 is P18932_T1_S1, time taken is 10.0204
Reply of Client Thread Id P18932_T3_S2 is P18932_T3_S2, time taken is 10.0208
. . . . . .

Observations

Compare the resource consumption and invocation performance measurement before and after  tuning “vbroker.ce.iiop.ccm.connectionMax=5” property at the Client side.

Client Memory (KB)  Client Threads Client Sockets No. successful invocations
Before Tuning 12400 21 10 20
After Tuning 12392 11 5 10

Key observations after tuning:

  • The number of sockets created by the Client is lesser.
  • Number of successful invocations is lesser.
  • NO_RESOURCES exceptions are thrown for the failed invocations.

Explanation

By default, the Client Engine connection manager does not restrict the number of concurrent outgoing connections to the Servers (i.e. vbroker.ce.iiop.ccm.connectionMax=0). That's why the Client can successfully make all the invocations to the 10 Servers concurrently. But after setting "connectionMax" to 5, the Client can only make invocations to 5 of the Servers concurrently. The failed invocations to the remaining 5 Servers result in NO_RESOURCES exceptions. The NO_RESOURCES exception is thrown when the Client Engine fails to find any cached or inactive connection that can be closed to make way for a new connection. The Client application implementation logic must handle the exception gracefully, such as by logging an error message (similar to this example), retrying the invocation later, or notifying the user about the error. Not catching the exception will cause the application to crash.

This feature is useful when the Client makes invocations to a very large number of Servers simultaneously when it is under heavy load. As a result, too many outgoing connections may be established, thus using up the process's file descriptor resources. This may deprive other modules in the same process of the same resources, and destabilize the whole application. If your application requires a higher file descriptor limit, you may increase the soft limit using "ulimit" system utility or the hard limit by tuning the operating system.

The file descriptor resource issues and resolutions encounter here is similar to what we have discussed in the [[Server Engine connectionMax]] article. The difference is that we are dealing with outgoing connections at the Client side ORB in this article, while for the other [[Server Engine connectionMax|article]], we are dealing with the incoming connections at the Server side ORB.

As you can see, the possible side effect of setting Client Engine "connectionMax" is lower invocation throughput. You also need additional application implementation logic to handle the NO_RESOURCES exception gracefully. But if you tune it appropriately, you can achieve a more stable application with an acceptable level of performance. As usual, you need to perform benchmark and stability tests on your application under peak load condition to find the optimal value.

The Client Engine "vbroker.ce.iiop.ccm.connectionMax" property is also applicable to VBJ.

In the next article, we will discuss another client side connection management property, i.e. vbroker.ce.iiop.ccm.connectionCacheMax, which can be tuned to control the socket resource consumption.

[[Server Engine connectionMaxIdle|Back]]  |  [[Client Engine connectionCacheMax|Next]]

Labels (1)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
2 of 2
Last update:
‎2020-03-13 21:06
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.