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-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
