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/09/05 13:00:33 UTC
[jira] Created: (QPID-578) AMQChannel.queueDeletion causes unacked
msgs to be discarded.
AMQChannel.queueDeletion causes unacked msgs to be discarded.
-------------------------------------------------------------
Key: QPID-578
URL: https://issues.apache.org/jira/browse/QPID-578
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: M2
Reporter: Martin Ritchie
Fix For: M2.1
Currently when a queue is deleted the Channel gets a call back and checks through the unacknowledged map for any messages that were on that queue to purge. This will cause an issue if the client then decides to ack one of the messges. But more problematically, if the message is persistent when the consumer is closed the unack messges will be rejected. This Reject handler will attempt to requeue but will need to look up the meta data to find out info about the message. That meta data will have been purged when the queueDelete callback was done so the Rejecthandler will see a NullPointerException.
Solution is to leave messages in the unacked map allowing, late acking and rejecting. Obviously when the reject occurs without a DeadLetterQueue the messages can only be dropped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-578) AMQChannel.queueDeletion causes unacked
msgs to be discarded.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-578:
--------------------------------
Attachment: Qpid-578-POTENTIAL-JustIgnoreProblemsOnReject.patch
Here is one potiential solution.
I'm not sure what the correct approach is.
Having AMQChannel not purge the messages seems sensible to me. As a client should be allowed to ack msgs it already has prefetched.
This patch simply stops the BasicRejectMH from attempting to requeue bad msgs
> AMQChannel.queueDeletion causes unacked msgs to be discarded.
> -------------------------------------------------------------
>
> Key: QPID-578
> URL: https://issues.apache.org/jira/browse/QPID-578
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M2.1
>
> Attachments: Qpid-578-POTENTIAL-JustIgnoreProblemsOnReject.patch
>
>
> Currently when a queue is deleted the Channel gets a call back and checks through the unacknowledged map for any messages that were on that queue to purge. This will cause an issue if the client then decides to ack one of the messges. But more problematically, if the message is persistent when the consumer is closed the unack messges will be rejected. This Reject handler will attempt to requeue but will need to look up the meta data to find out info about the message. That meta data will have been purged when the queueDelete callback was done so the Rejecthandler will see a NullPointerException.
> Solution is to leave messages in the unacked map allowing, late acking and rejecting. Obviously when the reject occurs without a DeadLetterQueue the messages can only be dropped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-578) AMQChannel.queueDeletion causes unacked
msgs to be discarded.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-578:
--------------------------------
Fix Version/s: (was: M2.1)
M3
> AMQChannel.queueDeletion causes unacked msgs to be discarded.
> -------------------------------------------------------------
>
> Key: QPID-578
> URL: https://issues.apache.org/jira/browse/QPID-578
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M3
>
> Attachments: Qpid-578-AMQChannel-DontDiscardMsg.patch, Qpid-578-POTENTIAL-JustIgnoreProblemsOnReject.patch
>
>
> Currently when a queue is deleted the Channel gets a call back and checks through the unacknowledged map for any messages that were on that queue to purge. This will cause an issue if the client then decides to ack one of the messges. But more problematically, if the message is persistent when the consumer is closed the unack messges will be rejected. This Reject handler will attempt to requeue but will need to look up the meta data to find out info about the message. That meta data will have been purged when the queueDelete callback was done so the Rejecthandler will see a NullPointerException.
> Solution is to leave messages in the unacked map allowing, late acking and rejecting. Obviously when the reject occurs without a DeadLetterQueue the messages can only be dropped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-578) AMQChannel.queueDeletion causes unacked
msgs to be discarded.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie reassigned QPID-578:
-----------------------------------
Assignee: (was: Martin Ritchie)
> AMQChannel.queueDeletion causes unacked msgs to be discarded.
> -------------------------------------------------------------
>
> Key: QPID-578
> URL: https://issues.apache.org/jira/browse/QPID-578
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Fix For: M3
>
> Attachments: Qpid-578-AMQChannel-DontDiscardMsg.patch, Qpid-578-POTENTIAL-JustIgnoreProblemsOnReject.patch
>
>
> Currently when a queue is deleted the Channel gets a call back and checks through the unacknowledged map for any messages that were on that queue to purge. This will cause an issue if the client then decides to ack one of the messges. But more problematically, if the message is persistent when the consumer is closed the unack messges will be rejected. This Reject handler will attempt to requeue but will need to look up the meta data to find out info about the message. That meta data will have been purged when the queueDelete callback was done so the Rejecthandler will see a NullPointerException.
> Solution is to leave messages in the unacked map allowing, late acking and rejecting. Obviously when the reject occurs without a DeadLetterQueue the messages can only be dropped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-578) AMQChannel.queueDeletion causes unacked
msgs to be discarded.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-578:
--------------------------------
Attachment: Qpid-578-AMQChannel-DontDiscardMsg.patch
This will prevent the messages being discarded during a queue deletion.
A test case needs created to highlight this problem and verify that this patch will address the issue.
There may be additional changes required in relation to QPID-621
> AMQChannel.queueDeletion causes unacked msgs to be discarded.
> -------------------------------------------------------------
>
> Key: QPID-578
> URL: https://issues.apache.org/jira/browse/QPID-578
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M2.1
>
> Attachments: Qpid-578-AMQChannel-DontDiscardMsg.patch, Qpid-578-POTENTIAL-JustIgnoreProblemsOnReject.patch
>
>
> Currently when a queue is deleted the Channel gets a call back and checks through the unacknowledged map for any messages that were on that queue to purge. This will cause an issue if the client then decides to ack one of the messges. But more problematically, if the message is persistent when the consumer is closed the unack messges will be rejected. This Reject handler will attempt to requeue but will need to look up the meta data to find out info about the message. That meta data will have been purged when the queueDelete callback was done so the Rejecthandler will see a NullPointerException.
> Solution is to leave messages in the unacked map allowing, late acking and rejecting. Obviously when the reject occurs without a DeadLetterQueue the messages can only be dropped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-578) AMQChannel.queueDeletion causes unacked
msgs to be discarded.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie reassigned QPID-578:
-----------------------------------
Assignee: Martin Ritchie
> AMQChannel.queueDeletion causes unacked msgs to be discarded.
> -------------------------------------------------------------
>
> Key: QPID-578
> URL: https://issues.apache.org/jira/browse/QPID-578
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M2.1
>
>
> Currently when a queue is deleted the Channel gets a call back and checks through the unacknowledged map for any messages that were on that queue to purge. This will cause an issue if the client then decides to ack one of the messges. But more problematically, if the message is persistent when the consumer is closed the unack messges will be rejected. This Reject handler will attempt to requeue but will need to look up the meta data to find out info about the message. That meta data will have been purged when the queueDelete callback was done so the Rejecthandler will see a NullPointerException.
> Solution is to leave messages in the unacked map allowing, late acking and rejecting. Obviously when the reject occurs without a DeadLetterQueue the messages can only be dropped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-578) AMQChannel.queueDeletion causes unacked
msgs to be discarded.
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack updated QPID-578:
----------------------------------
Fix Version/s: (was: M4)
Moving items not being worked on afaik out of M4 Fix Version
> AMQChannel.queueDeletion causes unacked msgs to be discarded.
> -------------------------------------------------------------
>
> Key: QPID-578
> URL: https://issues.apache.org/jira/browse/QPID-578
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Attachments: Qpid-578-AMQChannel-DontDiscardMsg.patch, Qpid-578-POTENTIAL-JustIgnoreProblemsOnReject.patch
>
>
> Currently when a queue is deleted the Channel gets a call back and checks through the unacknowledged map for any messages that were on that queue to purge. This will cause an issue if the client then decides to ack one of the messges. But more problematically, if the message is persistent when the consumer is closed the unack messges will be rejected. This Reject handler will attempt to requeue but will need to look up the meta data to find out info about the message. That meta data will have been purged when the queueDelete callback was done so the Rejecthandler will see a NullPointerException.
> Solution is to leave messages in the unacked map allowing, late acking and rejecting. Obviously when the reject occurs without a DeadLetterQueue the messages can only be dropped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.