Broker connection to AMQ suddenly stops communication

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Broker connection to AMQ suddenly stops communication

Joe2017
Hello,

We have broker application running under WAS application which uses AMQ
message delivery flow.
As of recent, message delivery to AMQ from Broker Application fails, and a
recycle of Broker Application and AMQ resumes message delivery.

Broker app is configured to connect to AMQ with default values of -
randomize=true&timeout=3000
There are 4 AMQ endpoints with failoverURL as failoverurl =
failover:(ssl://<endpoint1>:<port>, etc....


We see this event in Broker Logs when message flow ceases

FailoverTrans I org.apache.activemq.transport.failover.FailoverTransport
doReconnect Successfully connected to....

Repeats, but message flow does not resume unless recycled as mentioned
above.

Any thoughts on this or additional data needed to assist with continued
analysis?



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: Broker connection to AMQ suddenly stops communication

Tim Bain
You say that you're using a failover URL with four brokers within it; are
those brokers networked together, or standalone? Do all of them have
messages, or are some of them busy and others have no messages (such that if
your consumer failed over to certain ones, it would be expected behavior for
no messages to be delivered)?

I'm a little skeptical that re-establishing message flow requires a restart
of both the broker and the consumer (I assume that's what you mean by
"Broker Application and AMQ" - "Broker Application" == "the broker" and
"AMQ" = "the consumer"; if that's not what you meant, please restate your
observations using the nouns "broker", "producer", and "consumer".) I'd
expect that only one or the other would require a restart in order to
resolve whatever error is occurring; problems that require a reset of both
the broker and the consumer are pretty rare, though it's certainly possible.
But I'll push back a little and ask whether you've tried resetting only the
broker, and then resetting everything and reproducing the problem and
resetting only the consumer to prove that the problem is solved only when
both are reset but not when only one (either one) is. If it truly requires
both, does the order matter?

Have you used a JMX viewer such as JConsole attached to the broker to
investigate the state of the consumer following a failover? Do the JMX
statistics indicate that messages are being dispatched but not acknowledged,
or that they're not being dispatched to the consumer in the first place?

Also, are there any less-frequent configurations (e.g. message groups) that
you're using that might be playing into this? And what version of ActiveMQ
are you using?

Tim



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html