Packet acknowledge failed after failover

Hello,

We're running MQ 3.5 SP1 EE and we are wondering how to deal with the following problem. We have a client that consists of 2 producers and 1 consumer. There is a single connection for the client. Each producer creates its own session with:createSession(TRANSACTED_SESSION,Session.AUTO_ACKNOWLEDGE)

The consumer creates its session with:

createSession(TRANSACTED_SESSION,Session.DUPS_OK_ACKNOWLEDGE)

We have the following reconnect settings:imqReconnectEnabled =true

imqReconnectAttempts = 1

imqAddressListIterations = -1

imqReconnectInterval = 30000

imqAddressListBehavior = RANDOM

Sometimes when we kill one of our cluster servers, the client threads begin throwing exceptions as follows. From the send() method from one of the producers:

com.sun.messaging.jms.JMSException: [C4000]: Packet acknowledge failed.

From the send() method of the other producer (a few seconds later):com.sun.messaging.jms.JMSException: [C4001]: Write packet failed. - cause: java.net.SocketException: Socket is closed

Finally, an exception is caught by the consumer's exception listener:

JMSException caught: [C4002]: Read packet failed. - cause: java.net.SocketException: Socket is closed

What is the best way to recover from this? We were thinking of closing the connection, reopening, and starting all sessions again. Is there anything smarter we can do?

Kernel: 2.4.21-9.0.3.ELsmp

Dist: RedHat ES 3.0

Thanks,

Aaron

[1604 byte] By [aeddydev] at [2007-11-25 17:15:07]
# 1

There are a few options you may try for the connection recovery:

Option 1. If the killed broker will be restarted, you may increase the value of the "imqReconnectAttempts" property.

For example,

imqReconnectAttempts = 10

The above property will instruct the MQ client runtime to reconnect (to the same broker) 10 times (30 seconds interval for your case) before calling the connection's exception listener.

Option 2. Use "imqAddressList" to specify a list of message server addresses (one or more), separated by commas, each corresponding to a different broker instance to which a client runtime can connect.

Please see the "Sun ONE Message Queue 3.5 Java Client Developer's Guide", Chapter 4 "Configuring the MQ Client Runtime" for detailed information and examples:

http://docs.sun.com/source/817-3728/runtime.html#wp27058

Option 3. Handle reconnect and recreate JMS objects from the application. For MQ, when the connection exception listener is called, the current connection is broken. You may simply reconnect and recreate all JMS objects from the exception listener. The old connection will be closed by the MQ client runtime. The application does not require to close the connection in the exception listener.

chiaming

chiaming.yang at 2007-7-3 10:50:45 > top of Java-index,Application & Integration Servers,Sun Java System Message Queue...
# 2

Thanks for your response.

> Option 2. Use "imqAddressList" to specify a list of

> message server addresses (one or more), separated by

> commas, each corresponding to a different broker

> instance to which a client runtime can connect.

The imqAddressList property is already set (sorry, I should have mentioned this) and there is another broker server active. The problem is that the clients don't reconnect to the other server once one thread receives a "packet acknowledge failed" in the send() method. Subsequent calls to send() throw "socket is closed" instead of auto-reconnecting. Under normal conditions, ie. a local LAN, the reconnection works fine (clients auto-reconnect as expected and no exceptions are thrown). However, we are testing over a low bandwidth satellite and once we receive the "socket is closed" exception, it appears that the auto-reconnect will no longer work.

> Option 3. Handle reconnect and recreate JMS objects

> from the application. For MQ, when the connection

> exception listener is called, the current connection

> is broken. You may simply reconnect and recreate all

> JMS objects from the exception listener. The old

> connection will be closed by the MQ client runtime.

> The application does not require to close the

> e connection in the exception listener.

This may be the only viable option in our case.

Aaron

aeddydev at 2007-7-3 10:50:45 > top of Java-index,Application & Integration Servers,Sun Java System Message Queue...