You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org> on 2007/07/17 11:31:04 UTC

[jira] Created: (QPID-540) Transient Broker throws NullPointerException and locks up.

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.


[jira] Resolved: (QPID-540) Transient Broker throws NullPointerException and locks up.

Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Ritchie resolved QPID-540.
---------------------------------

    Resolution: Fixed

Prevent NPE when purging message from the main _message queue in the ConcurrentSelectorDeliveryManager that have been delivered via a Subscribers _messageQueue. Ensuring that any expired messages are still correctly handled. i.e. the Queue size/depth is reduced and the message correctly dequeued from the underlying store.

> 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.