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/05/28 17:37:45 UTC
[jira] Created: (QPID-1101) DestWildExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
DestWildExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
--------------------------------------------------------------------------------------------------
Key: QPID-1101
URL: https://issues.apache.org/jira/browse/QPID-1101
Project: Qpid
Issue Type: Bug
Components: Java Broker
Reporter: Martin Ritchie
Summary:
When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
Steps to Reproduce:
This is a race condition so can be difficult but:
Using the broker with the BDBStore Module.
Set up a client that reads from queue1 and replies to the JMSReplyTo.
Set up client2 that reads from a tempQueue.
Use client2 to send two messages (with tempQueue as the replyTo) to queue1
When you receive message 1 on client2 close the consumer
If this is running inVM then the consumer close should occur as message 2 is routing.
Restart the broker and it should fail to start with a MetaData not found for message 5 error.
Defect Identification:
As above, the shallow copy of enqueued queues is being modifed during routing.
Proposed Changes:
Make a copy of the list
Swap this:
payload.enqueue(queues);
to
payload.enqueue(new ArrayList<AMQQueue>(queues));
Test Strategy:
QueueDeleteRouteTest to be provided
This must be done on trunk then back merged.
Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie reassigned QPID-1101:
------------------------------------
Assignee: Aidan Skinner (was: Martin Ritchie)
Hey, can you review this change please.
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Aidan Skinner
> Fix For: M4
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aidan Skinner updated QPID-1101:
--------------------------------
Status: Open (was: Ready To Review)
Please don't add constructors which are only used by tests. It should write to an xml file and use the existing method for it.
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Aidan Skinner
> Fix For: M4
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aidan Skinner updated QPID-1101:
--------------------------------
Fix Version/s: (was: M3)
M4
Don't thnk this is worth rerolling M3 for.
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M4
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-1101:
---------------------------------
Summary: DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted. (was: DestWildExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.)
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Fix For: M3
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie reassigned QPID-1101:
------------------------------------
Assignee: Aidan Skinner (was: Martin Ritchie)
Point taken on the creation of the constructors for testing adding extra support overhead.
Can you review the rest of the test in isolation I shall perform the fix in QPID-1103 as this talks directly to the ability to provide configuration for broker start up.
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Aidan Skinner
> Fix For: M4
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aidan Skinner resolved QPID-1101.
---------------------------------
Resolution: Fixed
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Aidan Skinner
> Fix For: M4
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack reopened QPID-1101:
------------------------------------
Needs to be merged to trunk and verified (re-tested) on M2.1.x
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M3
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-1101:
---------------------------------
Status: Ready To Review (was: In Progress)
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M4
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634169#action_12634169 ]
Martin Ritchie commented on QPID-1101:
--------------------------------------
Whilst this isn'r really the right location to discuss the BDB module this is the cause of this failure.
There are number of tests that are part of the BDB Module that correspond to M2.1 and M2 which succeed. These tests were never moved to the M3 equivalent (refactored) branch. As a result they have never been run... and having coped the test over they fail, highlighting this issue is still present.
For those with interest the test is QueueDeleteWhilstRoutingTest, these tests should perhaps be moved to Apache and made generic enough to run with all persistent store currently configured.
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M3
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601658#action_12601658 ]
Martin Ritchie commented on QPID-1101:
--------------------------------------
Changes Commited to M2.x and merged to M2.1.x
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M3
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634341#action_12634341 ]
Rob Godfrey commented on QPID-1101:
-----------------------------------
In the trunk code on Apache the intent is to leave the ArrayLists referenced by the Index objects immutable, and thus safe to be returned. If an addition or removal from the bindings is made, a copy of the list is created and re-inserted into the Index which should remove the need for a copy to be made on each route operation (the reasoning being that route() is *far* more common that adding or removing a binding - so you want to move the expense of the array copy there). Since the size of the arraylist of queues that a message is being routed to should therefore never change between incrementing the ref count and placing on the queue I am surprised this is the issue that is you are seeing with the BDB store. Can you explain in more detail the scenario you are witnessing?
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M3
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie resolved QPID-1101.
----------------------------------
Resolution: Fixed
Fixed on M2.1 refactor took care of issue.
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M3
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-1101:
---------------------------------
Status: Ready To Review (was: In Progress)
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M4
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie reassigned QPID-1101:
------------------------------------
Assignee: Martin Ritchie
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M3
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aidan Skinner reassigned QPID-1101:
-----------------------------------
Assignee: Martin Ritchie (was: Aidan Skinner)
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M4
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1101) DestNameExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636584#action_12636584 ]
Martin Ritchie commented on QPID-1101:
--------------------------------------
Changes made to allow test in BDB Store Module to run testing this change.
> DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M4
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1101) DestWildExchange uses shallow copy of
queues for routing, causing routing to fail if queueDeleted.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-1101:
---------------------------------
Fix Version/s: M3
Affects Version/s: M2
M2.1
> DestWildExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-1101
> URL: https://issues.apache.org/jira/browse/QPID-1101
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Fix For: M3
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Summary:
> When testing with the BDBStore module it was noted that on occasion a mesage would be enqueued on a queue but the Metadata was not in the DB.
> This is due to the the fact that when routing takes place a shallow copy of queues the message has been enqueued to is returned by the DestNameExchange. If the queue is deleted before the message can be routed then it is removed from the list and never routed. This results in the message being purged from the DB but the enqueued reference remaining.
> The solution is to make a deep copy so that the DestNameExchange can modify the list without affecting routing.
> Steps to Reproduce:
> This is a race condition so can be difficult but:
> Using the broker with the BDBStore Module.
> Set up a client that reads from queue1 and replies to the JMSReplyTo.
> Set up client2 that reads from a tempQueue.
> Use client2 to send two messages (with tempQueue as the replyTo) to queue1
> When you receive message 1 on client2 close the consumer
> If this is running inVM then the consumer close should occur as message 2 is routing.
> Restart the broker and it should fail to start with a MetaData not found for message 5 error.
> Defect Identification:
> As above, the shallow copy of enqueued queues is being modifed during routing.
> Proposed Changes:
> Make a copy of the list
> Swap this:
> payload.enqueue(queues);
> to
> payload.enqueue(new ArrayList<AMQQueue>(queues));
> Test Strategy:
> QueueDeleteRouteTest to be provided
> This must be done on trunk then back merged.
> Difficulties exist as the trunk now uses QpidTestCase which is not capable of running multiple InVM brokers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.