DefaultIOExceptionHandler - dispatching SuppressReplyException to client side as ConnectionError

[ra...@centrum.cz]

Hello,
Could you please explain me problem/question relates to IOExceptionHandler?

On broker side, I use DefaultIOExceptionHandler, which triggers broker stop and throws SuppressReplyException("ShutdownBrokerInitiated", exception).

On client side I use failover transport and I have "one shared JMS connection" stored in Spring CachingConnectionFactory.

The problem is that sometimes (sometimes yes, sometimes no) SuppressReplyException("ShutdownBrokerInitiated") is
dispatched/transffered to client side as ConnectionError. If SuppressReplyException is transferred,
ActiveMQConnection.onException() is invoked, which finally causes that "shared JMS connection"
stored in Spring CachingConnectionFactory is invalidated. Then failover starts your work and successfully reconnects to
another instance of AMQ Broker. The problem occurs at the moment, when application needs JMS connection. In this moment
new FailoverTransport/Connection is created (because "shared JMS connection" is invalidated - null value) and AMQ Broker
rejects connection with "already connected from tcp://..." (I use jms.clientID in broker url).


Client side logs:

INFO {ActiveMQ Connection Executor: ...} [CachingConnectionFactory] Encountered a JMSException - resetting the underlying JMS Connection
javax.jms.JMSException: ShutdownBrokerInitiated
WARN {ActiveMQ Transport: ...} [FailoverTransport] Transport (tcp://...) failed, attempting to automatically reconnect
INFO {ActiveMQ Task-9} [FailoverTransport] Successfully reconnected to tcp://...
INFO {ActiveMQ Task-1} [FailoverTransport] Successfully connected to tcp://...
WARN ... nested exception is javax.jms.InvalidClientIDException: Broker: ... - Client: ... already connected from tcp://...


Question:
Should be SuppressReplyException always dispatched to client side as ConnectionError (by design)?

Note:
I guess (AFAIK), there is a problem related to threads concurrency, which is responsible for situation,
when SuppressReplyException is sometimes dispatched and sometimes not.
 - DefaultIOExceptionHandler starts the thread to stop broker
 - TransportConnection.serviceException(...) is dispatching SuppressReplyException only until TransportConnection is not
   "stopping" (see !stopping.get() in serviceException(...) method)
 - but TransportConnection is stopped by BrokerService.stop() method (triggered by DefaultIOExceptionHandler)

I still use ActiveMQ 5.16.7 (java 8), but the code seems same like in latest version.

Thank you for any feedback.
Radek Kraus.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact