Hello,
there's a pretty strange behaviour with one of our applications in our
development environment. We already had ActiveMQ in use with Camel
without problems. Some days ago we configured Log4j2 with a JMSQueue
appender in order to send logs to a ActiveMQ server. That works ...
basically.
While we could not observe problems with connecting to ActiveMQ
instances on localhost we occasionally run into problems when connecting
to a remote ActiveMQ 5.10 in our LAN.
Obviously Log4j initializes the appender right upon application start.
This works sometimes with the remote ActiveMQ but then suddenly fails
(there are other clients connected using other queues on that server).
The application then simply sits there, doing nothing besides pinging
the connection.
The command flow in Wireshark looks like this:
- WireFormatInfo (Server)
- WireFormatInfo (Client)
- BrokerInfo
- ConnectionInfo
- ConnectionControl
- Response
- ConsumerInfo
- multiple MessageDispatch for some advisory messages
- Response for the ConsumerInfo
The command to connect to our destination queue is never sent.
Please note: Wireshark complains about the dispatched advisory packets
being corrupt, but I can think of a Wireshark problem here.
We have another instance of ActiveMQ on the server in question an
meanwhile connections to this one do fail, too. The configuration is the
default one, besides listening ports changed and except for OpenWire
other protocols removed.
While testing we unpacked a third ActiveMQ on the same host and this one
does work. Note: no advisories sent when connecting to this one.
On the problematic instances we can see a topic
ActiveMQ.Advisory.TempQueue
... with an increasing counter of enqueued messages.
On the newly created/unpacked instance the Topic doesn't even appear (by
just booting the given application). Only ActiveMQ.Advisory.Queue does
exist.
I now figured that I can circumvent the dead-lock by using
watchTopicAdvisories=false
on the providerUrl for the JMSQueue.
From what I've debugged it looks like ActiveMQ hangs in a
FutureResponse that never gets the right command input from the
ResponseCorrelator.
Is it possible that the client gets confused by advisories being sent
before receiving the Response to the ConsumerInfo command?
Regards,
mdo
there's a pretty strange behaviour with one of our applications in our
development environment. We already had ActiveMQ in use with Camel
without problems. Some days ago we configured Log4j2 with a JMSQueue
appender in order to send logs to a ActiveMQ server. That works ...
basically.
While we could not observe problems with connecting to ActiveMQ
instances on localhost we occasionally run into problems when connecting
to a remote ActiveMQ 5.10 in our LAN.
Obviously Log4j initializes the appender right upon application start.
This works sometimes with the remote ActiveMQ but then suddenly fails
(there are other clients connected using other queues on that server).
The application then simply sits there, doing nothing besides pinging
the connection.
The command flow in Wireshark looks like this:
- WireFormatInfo (Server)
- WireFormatInfo (Client)
- BrokerInfo
- ConnectionInfo
- ConnectionControl
- Response
- ConsumerInfo
- multiple MessageDispatch for some advisory messages
- Response for the ConsumerInfo
The command to connect to our destination queue is never sent.
Please note: Wireshark complains about the dispatched advisory packets
being corrupt, but I can think of a Wireshark problem here.
We have another instance of ActiveMQ on the server in question an
meanwhile connections to this one do fail, too. The configuration is the
default one, besides listening ports changed and except for OpenWire
other protocols removed.
While testing we unpacked a third ActiveMQ on the same host and this one
does work. Note: no advisories sent when connecting to this one.
On the problematic instances we can see a topic
ActiveMQ.Advisory.TempQueue
... with an increasing counter of enqueued messages.
On the newly created/unpacked instance the Topic doesn't even appear (by
just booting the given application). Only ActiveMQ.Advisory.Queue does
exist.
I now figured that I can circumvent the dead-lock by using
watchTopicAdvisories=false
on the providerUrl for the JMSQueue.
From what I've debugged it looks like ActiveMQ hangs in a
FutureResponse that never gets the right command input from the
ResponseCorrelator.
Is it possible that the client gets confused by advisories being sent
before receiving the Response to the ConsumerInfo command?
Regards,
mdo