activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manfred Dohmen <manfred.doh...@gmail.com>
Subject Log4j2 JMSQueue appender hangs when connecting ActiveMQ
Date Mon, 01 Sep 2014 09:40:50 GMT
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







Mime
View raw message