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 2008/07/22 14:44:31 UTC
[jira] Created: (QPID-1186) [Client Race Condition] After Failover
client can ack last message from previous session.
[Client Race Condition] After Failover client can ack last message from previous session.
-----------------------------------------------------------------------------------------
Key: QPID-1186
URL: https://issues.apache.org/jira/browse/QPID-1186
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: M2.1
Reporter: Martin Ritchie
Summary:
There is no locking controlling the interaction of the Dispatcher and Failover threads.
If the Dispatcher thread is mid processing of a message and Failover occurs successfully the message will continue to be delivered to the consumer.
If that consumer session requires acknowledgement then the message will be acked when received, even though the message is now no longer valid in this new session.
Steps to Reproduce:
This is difficult to reproduce as it is a race condition. Adding a sleep in to the BasicMessageConsumer (L:669) notifyMessage(UnprocessedMessage) should do the trick in the (org.apache.qpid.test.client.failover) FailoverTest
Proposed Changes:
When failover occurs then the dispatcher needs to be stopped so that any message currently being processed is halted.
- It should not continue to deliver the message if failover starts as delivery to a message listener will not be able to ack the message, and the message will be redelivered, unless the session is NO_ACK.
When failover completes and clears the Consumer's state then we can be sure that the Dispatcher was not mid delivery with a message from a previous session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1186) [Client Race Condition] After Failover
client can ack last message from previous session.
Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aidan Skinner updated QPID-1186:
--------------------------------
Fix Version/s: M3
> [Client Race Condition] After Failover client can ack last message from previous session.
> -----------------------------------------------------------------------------------------
>
> Key: QPID-1186
> URL: https://issues.apache.org/jira/browse/QPID-1186
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M2.1
> Reporter: Martin Ritchie
> Fix For: M3
>
> Attachments: TEST-org.apache.qpid.test.client.failover.FailoverTest.txt
>
>
> Summary:
> There is no locking controlling the interaction of the Dispatcher and Failover threads.
> If the Dispatcher thread is mid processing of a message and Failover occurs successfully the message will continue to be delivered to the consumer.
> If that consumer session requires acknowledgement then the message will be acked when received, even though the message is now no longer valid in this new session.
> Steps to Reproduce:
> This is difficult to reproduce as it is a race condition. Adding a sleep in to the BasicMessageConsumer (L:669) notifyMessage(UnprocessedMessage) should do the trick in the (org.apache.qpid.test.client.failover) FailoverTest
> Proposed Changes:
> When failover occurs then the dispatcher needs to be stopped so that any message currently being processed is halted.
> - It should not continue to deliver the message if failover starts as delivery to a message listener will not be able to ack the message, and the message will be redelivered, unless the session is NO_ACK.
> When failover completes and clears the Consumer's state then we can be sure that the Dispatcher was not mid delivery with a message from a previous session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1186) [Client Race Condition] After Failover
client can ack last message from previous session.
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack updated QPID-1186:
-----------------------------------
Priority: Major (was: Blocker)
Discussions with MR & AS mean that we have moved this to Major priority since a) it's unlikely to happen and b) we have limited exposure to failover in terms of known use cases.
> [Client Race Condition] After Failover client can ack last message from previous session.
> -----------------------------------------------------------------------------------------
>
> Key: QPID-1186
> URL: https://issues.apache.org/jira/browse/QPID-1186
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M3
>
> Attachments: TEST-org.apache.qpid.test.client.failover.FailoverTest.txt
>
>
> Summary:
> There is no locking controlling the interaction of the Dispatcher and Failover threads.
> If the Dispatcher thread is mid processing of a message and Failover occurs successfully the message will continue to be delivered to the consumer.
> If that consumer session requires acknowledgement then the message will be acked when received, even though the message is now no longer valid in this new session.
> Steps to Reproduce:
> This is difficult to reproduce as it is a race condition. Adding a sleep in to the BasicMessageConsumer (L:669) notifyMessage(UnprocessedMessage) should do the trick in the (org.apache.qpid.test.client.failover) FailoverTest
> Proposed Changes:
> When failover occurs then the dispatcher needs to be stopped so that any message currently being processed is halted.
> - It should not continue to deliver the message if failover starts as delivery to a message listener will not be able to ack the message, and the message will be redelivered, unless the session is NO_ACK.
> When failover completes and clears the Consumer's state then we can be sure that the Dispatcher was not mid delivery with a message from a previous session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1186) [Client Race Condition] After Failover
client can ack last message from previous session.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-1186:
---------------------------------
Priority: Blocker (was: Major)
> [Client Race Condition] After Failover client can ack last message from previous session.
> -----------------------------------------------------------------------------------------
>
> Key: QPID-1186
> URL: https://issues.apache.org/jira/browse/QPID-1186
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Priority: Blocker
> Fix For: M3
>
> Attachments: TEST-org.apache.qpid.test.client.failover.FailoverTest.txt
>
>
> Summary:
> There is no locking controlling the interaction of the Dispatcher and Failover threads.
> If the Dispatcher thread is mid processing of a message and Failover occurs successfully the message will continue to be delivered to the consumer.
> If that consumer session requires acknowledgement then the message will be acked when received, even though the message is now no longer valid in this new session.
> Steps to Reproduce:
> This is difficult to reproduce as it is a race condition. Adding a sleep in to the BasicMessageConsumer (L:669) notifyMessage(UnprocessedMessage) should do the trick in the (org.apache.qpid.test.client.failover) FailoverTest
> Proposed Changes:
> When failover occurs then the dispatcher needs to be stopped so that any message currently being processed is halted.
> - It should not continue to deliver the message if failover starts as delivery to a message listener will not be able to ack the message, and the message will be redelivered, unless the session is NO_ACK.
> When failover completes and clears the Consumer's state then we can be sure that the Dispatcher was not mid delivery with a message from a previous session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1186) [Client Race Condition] After Failover
client can ack last message from previous session.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-1186:
---------------------------------
Attachment: TEST-org.apache.qpid.test.client.failover.FailoverTest.txt
Extracted testP2PFailoverWithMessagesLeft that demonstrates this issue
> [Client Race Condition] After Failover client can ack last message from previous session.
> -----------------------------------------------------------------------------------------
>
> Key: QPID-1186
> URL: https://issues.apache.org/jira/browse/QPID-1186
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M2.1
> Reporter: Martin Ritchie
> Attachments: TEST-org.apache.qpid.test.client.failover.FailoverTest.txt
>
>
> Summary:
> There is no locking controlling the interaction of the Dispatcher and Failover threads.
> If the Dispatcher thread is mid processing of a message and Failover occurs successfully the message will continue to be delivered to the consumer.
> If that consumer session requires acknowledgement then the message will be acked when received, even though the message is now no longer valid in this new session.
> Steps to Reproduce:
> This is difficult to reproduce as it is a race condition. Adding a sleep in to the BasicMessageConsumer (L:669) notifyMessage(UnprocessedMessage) should do the trick in the (org.apache.qpid.test.client.failover) FailoverTest
> Proposed Changes:
> When failover occurs then the dispatcher needs to be stopped so that any message currently being processed is halted.
> - It should not continue to deliver the message if failover starts as delivery to a message listener will not be able to ack the message, and the message will be redelivered, unless the session is NO_ACK.
> When failover completes and clears the Consumer's state then we can be sure that the Dispatcher was not mid delivery with a message from a previous session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1186) [Client Race Condition] After Failover
client can ack last message from previous session.
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack updated QPID-1186:
-----------------------------------
Fix Version/s: (was: M4)
Descoping items not being worked on for M4 into Unknown Fix Version for now
> [Client Race Condition] After Failover client can ack last message from previous session.
> -----------------------------------------------------------------------------------------
>
> Key: QPID-1186
> URL: https://issues.apache.org/jira/browse/QPID-1186
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Attachments: TEST-org.apache.qpid.test.client.failover.FailoverTest.txt
>
>
> Summary:
> There is no locking controlling the interaction of the Dispatcher and Failover threads.
> If the Dispatcher thread is mid processing of a message and Failover occurs successfully the message will continue to be delivered to the consumer.
> If that consumer session requires acknowledgement then the message will be acked when received, even though the message is now no longer valid in this new session.
> Steps to Reproduce:
> This is difficult to reproduce as it is a race condition. Adding a sleep in to the BasicMessageConsumer (L:669) notifyMessage(UnprocessedMessage) should do the trick in the (org.apache.qpid.test.client.failover) FailoverTest
> Proposed Changes:
> When failover occurs then the dispatcher needs to be stopped so that any message currently being processed is halted.
> - It should not continue to deliver the message if failover starts as delivery to a message listener will not be able to ack the message, and the message will be redelivered, unless the session is NO_ACK.
> When failover completes and clears the Consumer's state then we can be sure that the Dispatcher was not mid delivery with a message from a previous session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.