qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Updated: (QPID-1101) DestNameExchange uses shallow copy of queues for routing, causing routing to fail if queueDeleted.
Date Fri, 03 Oct 2008 10:20:44 GMT

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


Mime
View raw message