2009/9/18 Gordon Sim <[email protected]>: > On 09/18/2009 04:58 PM, Martin Ritchie wrote: >> >> Hi CPP broker devs, >> >> I'm just looking at the RollbackOrderTest and wondered what the CPP >> broker will do if the client attempts to release a range of >> deliveryTags that the broker no longer has? > > It will ignore the request for any id in the ranges specified that does not > correspond to a known delivery.
Ok that is what the current java broker does but I think it is masking an ordering issue, at least with the Java broker. The Java broker keeps a list of unacked messages which have been sent to a consumer, which, when rejected are returned to the main queue for consumption. When the TxRollback is recevied the contents of the unacked queue are resent before the contents of the main queue. This means that all rejects must be sent before the TxRollback or the contents of the unacked queue will jump ahead of the main queue. How does the CPP broker maintain the list of messages sent to the client? I haven't yet had time to write a test using AMQP frames that simulates the race condition but it is possible for the java client dispatcher to reject a single message after the TxRollback is sent. For the Java broker this means a message (also most likey not the front message on the queue) will be held by the dispatcher whilst the session rollback is performed. When the rollback is complete the dispatcher then rejects the message it is holding. Problem is the Java broker ignores this as the message that was to be rejected has already been resent to the client. The problem is the message was resent before any of the messages from the main queue, which may be out of order. My re-reading of the JMS Spec suggests that this might actually be ok, as the message is marked redelivered. However, it doesn't seem right to me given that we can actually perform in order delivery on rollback. Just wondered if you have ever seen a failure of RollbackOrderTest. The test doesn't send very many messages so the Dispatcher thread may actually get to process all the messages before the rollback is initiated. I noticed that this test is actually disabled against the Java broker, so the test has been 'passing' for ages. Cheers Martin >> In the Java broker the releases are done as BasicRejects in the 08/09 >> code path and the broker currently only logs out warning if it does >> not have a record of the delivery tag. >> >> I was wondering if the CPP broker does anything similar, mainly so I >> can see if the issue that I've seen (QPID-1871) affects the 0-10 code >> path. I feel it should but I don't know enough about how the CPP >> broker works to make that call. >> >> Cheers >> >> Martin > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
