Cause of“Session is closed” exception.
Article ID: KB0087953
Updated On:
| Products | Versions |
|---|---|
| TIBCO Enterprise Message Service | - |
| Not Applicable | - |
Description
Resolution:
Environment:
= = = = = = =
All
Resolution:
= = = = = = =
The“Session is closed” exception is thrown when the application tries to use a session which was previously closed.
Even if the EMS client does not close the session by specifically calling session.close(), there might be a situation where the client connection was terminated by a network issue and the connection object could be physically closed. So if the EMS client still uses this logical connection/session object, you could get the "illegal state exception". The EMS server will not return an error code (exception) to the client until the client makes an erroneous call.
In past we have noticed similar issue for zero window (lack of CPU resources) / TCP Window Full symptom with EMS application. The issues were resolved by CPU resource tuning and TCP tuning.
This exception can also be seen when the server has timed out the connection created by the client application (due to a network glitch or the server being too busy), but the client is un-aware and uses a session created by the terminated connection to create/send/receive a message.
We would need some additional information covering the problem period to analyze the root cause of the problem:
1). EMS client API version
2). How many applications/connections are running when this exception is seen? Are you sharing one session for multiple threads?
3). Are you using a Fault Tolerance URL with this client?
4). The EMS server config files.
EMS server log files with “DEFAULT,+CONNECT,+PRODCONS” tracing enabled covering the problem period. If you can trace the connection associated with the problematic application in the logs (i.e., point us to the connectionID), or run this application as a separate user so we could identify the connections from it.
5). Enable client tracing using the command: set server client_trace=enabled
This would help us to see if there is some activity closing the session before the exception is raised on the client side. Also send the client log covering the problematic period. Again, if you run this application as a separate user you could apply client_trace for connections only from that user, e.g., set server client_trace=enabled user=<username>
6). CPU/Memory usage statistics of the EMS server covering the problem period.
7). If the client and the server run on separate machine collect a raw tcpdump/snoop captures from the EMS server box covering the problem period. Also, let us know the IP address of the EMS server and the problematic client box. You will need to run this as root.
Example: snoop –o <filename> -s 1600 or tcpdump –w <filename> -s 1600
8). Keep a script with the following commands running and collecting captures every 2 minutes. Create a text file "stats.script", which has the following commands:
time on
timeout 100
show server
show connections full
show consumers full
##############
show queue <affected queue>
<OR>
show topic <affected topic>
##############
show stat consumers
show stat producers
and then run this script using the following command:
tibjmsadmin -server emshost:port -ignore -script stats.script
Environment:
= = = = = = =
All
Resolution:
= = = = = = =
The“Session is closed” exception is thrown when the application tries to use a session which was previously closed.
Even if the EMS client does not close the session by specifically calling session.close(), there might be a situation where the client connection was terminated by a network issue and the connection object could be physically closed. So if the EMS client still uses this logical connection/session object, you could get the "illegal state exception". The EMS server will not return an error code (exception) to the client until the client makes an erroneous call.
In past we have noticed similar issue for zero window (lack of CPU resources) / TCP Window Full symptom with EMS application. The issues were resolved by CPU resource tuning and TCP tuning.
This exception can also be seen when the server has timed out the connection created by the client application (due to a network glitch or the server being too busy), but the client is un-aware and uses a session created by the terminated connection to create/send/receive a message.
We would need some additional information covering the problem period to analyze the root cause of the problem:
1). EMS client API version
2). How many applications/connections are running when this exception is seen? Are you sharing one session for multiple threads?
3). Are you using a Fault Tolerance URL with this client?
4). The EMS server config files.
EMS server log files with “DEFAULT,+CONNECT,+PRODCONS” tracing enabled covering the problem period. If you can trace the connection associated with the problematic application in the logs (i.e., point us to the connectionID), or run this application as a separate user so we could identify the connections from it.
5). Enable client tracing using the command: set server client_trace=enabled
This would help us to see if there is some activity closing the session before the exception is raised on the client side. Also send the client log covering the problematic period. Again, if you run this application as a separate user you could apply client_trace for connections only from that user, e.g., set server client_trace=enabled user=<username>
6). CPU/Memory usage statistics of the EMS server covering the problem period.
7). If the client and the server run on separate machine collect a raw tcpdump/snoop captures from the EMS server box covering the problem period. Also, let us know the IP address of the EMS server and the problematic client box. You will need to run this as root.
Example: snoop –o <filename> -s 1600 or tcpdump –w <filename> -s 1600
8). Keep a script with the following commands running and collecting captures every 2 minutes. Create a text file "stats.script", which has the following commands:
time on
timeout 100
show server
show connections full
show consumers full
##############
show queue <affected queue>
<OR>
show topic <affected topic>
##############
show stat consumers
show stat producers
and then run this script using the following command:
tibjmsadmin -server emshost:port -ignore -script stats.script
Issue/Introduction
Cause of“Session is closed” exception.
Feedback
Yes
No
Powered by
