Can A Tuxedo JSL Process Be Configured To Disconnect A Broken Firewall Connection (Doc ID 2227301.1)

Last updated on JANUARY 30, 2017

Applies to:

Oracle Tuxedo - Version 10.3.0 and later
Information in this document applies to any platform.

Goal

"Is there a way to configure Tuxedo JSL/JSH system process so that a broken Firewall connection can be detected and disconnected?"

 

Background:

User has both Tuxedo JOLT server listener,JSL, and  workstation server listener,WSL, processes configured in the ubb configuraton file with a MAXWSCLIENTS paramater value of 750.

When user encountered firewall issue, JOLT clients were disconnected; however, when firewall issue was resolved not all JOLT clients were able to re-establish the connection with a Tuxedo JSH system process (JOLT server handler).. 

User saw the following Tuxedo ULOG log entries:

000103.xxxx!TMSYSEVT.22939.1.0: LIBTUX_CAT:1490: WARN: .SysMachineFullMaxwsclients: xxxx capacity limit
...
000303.xxxx!TMSYSEVT.22939.1.0: LIBTUX_CAT:1490: WARN: .SysMachineFullMaxwsclients: xxxx capacity limit

 

Tuxedo JSL system process is configured in the ubb configuration file with following CLOPT parameter:

CLOPT="-A -- -n 0x0002nnnnnnnnnnnn -m 30 -M 50 -x 15 -K handler "

 

Analysis:

The LIBTUX_CAT:1490 warning messages logged in the Tuxedo ULOG were originated as a system event by the Tuxedo BBL system process. When the BBL discovered that the number of clients for the WSL
and JSL process(workstation and JOLT clients) reached its maximum configured value it posted a LIBTUX_CAT:1490 event and the Tuxedo TMSYSEVT system process logged it into the ULOG.
Normally, when a socket is closed unexpectedly then the following warning messages will be logged in the Tuxedo ULOG:

JOLT_CAT:1198 "WARN: Forced shutdown of client; user name '%s'; client name '%s"
JOLT_CAT:1199 "WARN: .SysClientDied: User %s on %s client died"

Cause Determination:

In this case a firewall is used but the socket entry in the firewall was not removed and the connections between firewall and JSH are still alive from firewall's point of view.  This is supported by that there was no JOLT_CAT:1098 nor JOLT_CAT:1099 logged in the Tuxedo ULOG.  Consequently, the JSH did not receive socket close events from the network layer and kept JOLT client contexts alive even though there were no network activities.

When the firewall problem was resolved eventually, and JOLT clients tried to reconnect with JSH, the MAXWSCLIENTS value was reached and caused some of those JOLT clients failure to reconnect.


 

Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms