Bernhard Trummer created AMQ-5575:
-------------------------------------
Summary: Stuck message in ActiveMQ after WebLogic (incl. MDB)
startup
Key: AMQ-5575
URL: https://issues.apache.org/jira/browse/AMQ-5575
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.11.0, 5.10.0, 5.8.0
Environment: Linux (Debian squeeze)
WebLogic Server 10.3.6.0 with a "Foreign Server" JMS module pointing to
ActiveMQ.
WebLogic and ActiveMQ running locally.
Reporter: Bernhard Trummer
The setup:
- ActiveMQ with the default configuration providing one queue.
- WebLogic server having
- a "Foreign Server" JMS module configured pointing to the ActiveMQ's queue
- a simple EJB3 MDB hooked up to this queue via XAConnectionFactory.
The issue is always reproducable as follows:
1. Shut down WebLogic
2. Start up ActiveMQ
3. Put a message (M1) into ActiveMQ's queue (e.g. via web frontend)
4. Start up WebLogic (including the simple EJB3 MDB deployment)
5. You'll see that the message M1 is consumed. The MDB logs it and the message
vanishes from the ActiveMQ web frontend => OK
6. Put another message (M2) into ActiveMQ's queue.
7. Put a third message (M3) into ActiveMQ's queue.
Expected behavior:
M2 and M3 are consumed by the MDB on WebLogic.
Actual behavior:
M2 is getting "stuck".
M3 is consumed correctly.
The next 15 messages you add to the ActiveMQ queue are consumed correctly.
The next message (MX) leads to a consumption of the previously stuck message
(M2) and the current message (MX).
After that, the behavior repeats with scenario step 6 above.
Some further notes:
1. Why 15/16 messages until the stuck message is consumed? Because ActiveMQ
shows 16 listeners when WebLogic is started up.
2. I can reproduce the issue every time.
3. It occurs with version 5.8.0, 5.10.0 and 5.11.0 of activemq (of course also
using the matching activemq-client jar in WebLogic).
4. If you leave out step 3 of the scenario (means: ensure that ActiveMQ's queue
is empty before WebLogic is started up), then everything is fine and no message
is getting stuck.
5. Good news is, that no message is getting lost without being consumed. But
it's still quite annoying in my current integration project I'm working on. :-)
Currently I'm trying to add trace logging into the activemq-client to get a
better idea on what's going on. What I can tell so far is, that the message M2
is indeed received by the client and enqueued into a
SimplePriorityMessageDispatchChannel instance correctly. But it looks like that
the dequeue() call is done on a different instance in this scenario.
Further I see, that some kind of "round robin" happens in the usage of these
Channel instances and that might be the reason, why M2 is eventually consumed
together with the 16th next message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
