Transient Broker throws NullPointerException and locks up.
----------------------------------------------------------
Key: QPID-540
URL: https://issues.apache.org/jira/browse/QPID-540
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: M2
Reporter: Martin Ritchie
Assignee: Martin Ritchie
Fix For: M2
During the testing with the transient configuration the broker threw the
following.
2007-07-11 12:34:24,187 INFO [pool-1278-thread-1] handler.QueueBindHandler
(QueueBindHandler.java:115) - Bind
ing queue Queue(my_queue)@10656878 to exchange
org.apache.qpid.server.exchange.DestNameExchange[amq.direct] wi
th routing key my_queue
Exception in thread "pool-1-thread-13" java.lang.NullPointerException
at
org.apache.qpid.server.queue.WeakReferenceMessageHandle.populateFromMessageMetaData(WeakReferenceMe
ssageHandle.java:80)
at
org.apache.qpid.server.queue.WeakReferenceMessageHandle.loadMessageMetaData(WeakReferenceMessageHan
dle.java:74)
at
org.apache.qpid.server.queue.WeakReferenceMessageHandle.getContentHeaderBody(WeakReferenceMessageHa
ndle.java:64)
at
org.apache.qpid.server.queue.AMQMessage.getContentHeaderBody(AMQMessage.java:328)
at org.apache.qpid.server.queue.AMQMessage.getSize(AMQMessage.java:906)
at
org.apache.qpid.server.queue.ConcurrentSelectorDeliveryManager.getNextMessage(ConcurrentSelectorDel
iveryManager.java:461)
at
org.apache.qpid.server.queue.ConcurrentSelectorDeliveryManager.sendNextMessage(ConcurrentSelectorDe
liveryManager.java:551)
at
org.apache.qpid.server.queue.ConcurrentSelectorDeliveryManager.processQueue(ConcurrentSelectorDeliv
eryManager.java:684)
at
org.apache.qpid.server.queue.ConcurrentSelectorDeliveryManager.access$200(ConcurrentSelectorDeliver
yManager.java:50)
at
org.apache.qpid.server.queue.ConcurrentSelectorDeliveryManager$Runner.run(ConcurrentSelectorDeliver
yManager.java:856)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
This must be due to a message being dequeued but still existing on the queue.
The problem is down to the use of selectors.
If a message is consumed via a selector it is marked as taken and delivered to
the consumer. If the reference count hits zero which it will if the message was
only sent to the one queue. Then the message will be dequeued and any
WeakReference Handles deleted. All as expected. HOWEVER,
The message is still on the main queue. A warning message is logged saying "We
could cleanup the main queue _messages here." It should say SHOULD.
The message is referenced by the main queue and the next subscription (without
a filter) that attempts to read from the queue will walk the _message queue.
The getNextMessage() method will purge the messages that have expired or been
taken. Such as this taken message from the filetered consumer. Problem is, here
we attempt to reduce the _totalMessageSize which has already been done when the
message was delivered. Thus in attempting to retrieve the size of the message
we need to access the Headers that were on a WeakReferenceHandle and so are now
null causing the NPE.
The solution is to only attempt to reduce the _totalMessageSize when we are
purging a message due to a time out. As this is the only path through the
purgeMessage() method that state the message should be purge and the message
has not already been delivered to a consumer of the queue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
