JMS connectivity

[Former Member]

Hi all,

my XI ver. is 3.22; over the last few day we had some "network issues" following which the JMS adapters stopped working. I had to "refresh" the adaptors (e.g., re-define the jms parameters). my 2 questions are:

1. what is the "educated" explanation for this phenomenon?

2. how can i workaround it?

Regards

Uri

[Former Member]

Note:

an "official" workaround is to use "CONNECTION_TEST_POLL=true" (jms receiver CC -->advanced -->additional parameters). it was not feasible since MQ team did not allow it.

[Former Member]

Also may be helpful:

Note 948016 - Websphere MQ reconnect issue for JMS receiver channel

Note 915410 - Problems with connection retry after JMS queue unavailabilit

[JoelTrinidade]

Hi Uri,

A very very educated explanation has been given by aashish , and regarding workaround is that you need to do a manual restart and if you would want to avoid that then try third party s/w like always up.

http://www.coretechnologies.com/products/AlwaysUp/

Regards

joel

[aashish_sinha]

Hi,

In a cluster with more than one server node, the typical JMS usage involves internal cluster communication with the central JMS server node.

The central JMS node can crash or become unavailable for a number of reasons - OutOfMemoryError, HotSpot error, hardware failure, network failure. In case the central node crashes or connection to it is lost, the JMS resources on other server nodes become unavailable and the applications are notified (according to the JMS specification) through all registered standard listeners (javax.jms.ExceptionListener). Upon receipt of such event, applications should normally recreate the JMS resources (connection, session, and so on) and the communication is automatically redirected to another running server node that becomes the central JMS (server) node. The old connections and resources are invalidated and all attempts to use them will result in the exceptions .

Since the failover of the JMS central node does not happen immediately, applications that use JMS resources should perform the recovery in a cycle waiting for a certain time before each attempt to reestablish the JMS connections. There is a short period of time before the reinitialization, during which the resources are not available.

If an application does not wait for a certain time (for example, 1 second) before the subsequent reconnection attempt, it is possible to create an infinite loop (an exception is thrown, then the application tries to reestablish the JMS connection and the same exception is thrown again) and occupy all the CPU resources, thus not letting the JMS recovery procedure complete for a reasonable time.

The exceptions can also appear if there are pending requests when the J2EE Engine is being shut down. In this case, the exceptions appear because the JMS service has already been shut down as part of the shutdown procedure before the completion of all user requests. In such cases, the exceptions can be ignored. To distinguish this case, you can compare the time when the exception occurred with the timestamp of the logs for the server shutdown in <server>/log/system/server.X.log.

A manual workaround when the application does not implement a JMS recovery mechanism would be to restart the application. Thus, the JMS connections used by the application will be initialized with a valid value at application startup.

Regards

Aashish Sinha

[Former Member]

Hi

We have EP 7.0 in MSCS cluster

Regards

Rao.

Edited by: Valeswararao Cheruku on May 8, 2009 12:13 PM