Negative Pending Message Count
------------------------------
Key: AMQ-3111
URL: https://issues.apache.org/jira/browse/AMQ-3111
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.4.0
Environment: Windows XP, ActiveMQ 5.4.0
Reporter: ashwini kuntamukkala
When a queue connection redelivery policy's max redelivery time is set to -1,
and the bad message which is failing constantly needs to be moved to exception
queue manually (JMX JConsole, ActiveMQ WebConsole), then dequeue is accounted
twice for the same message.
Say at time T0 queue is empty
queue has a registered listener
T1 => message gets put on the queue => enqueue = 1, dequeue = 0, pending = 1
T2 .. T3 .. T4..T5 this message is constantly failing because of some runtime
exception
Using ActiveMQ webconsole, we move this to exception queue...and have logic in
the consumer to commit the session if this is a redelivered message that does
not exist on the queue, Refer AMQ 3110
Then,
at T6
enqueue count = 1, dequeue count = 2, pending count = -1
Attached is the unit test showing this issue.
Please refer the log pasted below.
-------------------------
0 [JMX connector] INFO org.mortbay.log - Logging to
org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
2011-01-03 16:49:17,036 INFO (BrokerService) - Using Persistence Adapter:
MemoryPersistenceAdapter
2011-01-03 16:49:17,036 INFO (ManagementContext) - JMX consoles can connect to
service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
2011-01-03 16:49:17,036 INFO (BrokerService) - ActiveMQ 5.4.0 JMS Message
Broker (localhost) is starting
2011-01-03 16:49:17,036 INFO (BrokerService) - For help or more information
please see: http://activemq.apache.org/
2011-01-03 16:49:17,317 INFO (SchedulerBroker) - Scheduler using directory:
activemq-data\scheduler
2011-01-03 16:49:17,364 INFO (BrokerService) - ActiveMQ JMS Message Broker
(localhost, ID:akuntamukkala-2412-1294094957083-0:0) started
2011-01-03 16:49:17,411 INFO (TransportConnector) - Connector vm://localhost
Started
test.exception.queue
Mon Jan 03 16:49:17 CST 2011 : Number of messages in test.exception.queue = 1
Mon Jan 03 16:49:17 CST 2011 : Number of messages in test.queue = 1
Mon Jan 03 16:49:17 CST 2011 : test.queue : enqueue = 1, dequeue count = 0
Mon Jan 03 16:49:17 CST 2011 - Message received by consumer =
ID:akuntamukkala-2412-1294094957083-3:1:1:2:1
Mon Jan 03 16:49:18 CST 2011 - Message received by consumer =
ID:akuntamukkala-2412-1294094957083-3:1:1:2:1
Mon Jan 03 16:49:18 CST 2011 - Message received by consumer =
ID:akuntamukkala-2412-1294094957083-3:1:1:2:1
Mon Jan 03 16:49:19 CST 2011 : test.queue : enqueue = 1, dequeue count = 0
Mon Jan 03 16:49:19 CST 2011 - Message received by consumer =
ID:akuntamukkala-2412-1294094957083-3:1:1:2:1
Mon Jan 03 16:49:19 CST 2011 - Message received by consumer =
ID:akuntamukkala-2412-1294094957083-3:1:1:2:1
Mon Jan 03 16:49:20 CST 2011 - Message received by consumer =
ID:akuntamukkala-2412-1294094957083-3:1:1:2:1
Mon Jan 03 16:49:20 CST 2011 : Number of messages in test.queue after MOVE = 0
Mon Jan 03 16:49:20 CST 2011 : Number of messages in test.exception.queue after
MOVE = 2
Mon Jan 03 16:49:20 CST 2011 : test.queue : enqueue = 1, dequeue count = 1
Mon Jan 03 16:49:20 CST 2011 - Message received by consumer =
ID:akuntamukkala-2412-1294094957083-3:1:1:2:1
numberOfTimeMessageWasReceived 7
number of times message was received after moving 7
Mon Jan 03 16:49:23 CST 2011 : Final test.queue : enqueue = 1, dequeue count =
2, pending message count = -1
2011-01-03 16:49:23,739 INFO (BrokerService) - ActiveMQ Message Broker
(localhost, ID:akuntamukkala-2412-1294094957083-0:0) is shutting down
2011-01-03 16:49:23,739 INFO (TransportConnector) - Connector vm://localhost
Stopped
2011-01-03 16:49:23,770 INFO (BrokerService) - ActiveMQ JMS Message Broker
(localhost, ID:akuntamukkala-2412-1294094957083-0:0) stopped
-----
Please run the attached Junit test and see this issue. Since AMQ 3110 is still
unresolved, the only way we could get rid of the bad message being redelivered
despite having been moved to an exception queue was by checking the redelivery
counter and if the message was still on the queue, if not, then we acknowledge
the session so subsequent messages can be processed.
Thank you,
Ashwini Kuntamukkala
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
