Qpid C++ broker behavior questions

[James Birdsall <jb...@microsoft.com>]

I'm doing the test plan for the persistence provider that Steve Huston is working on, and I've hit a number of points where I'm not clear on what the expected behavior is. If someone could point me in the right direction, it would be much appreciated!


*         If a client sends a persistent message to a persistent queue and the broker restarts before the client receives completion of the send, what happens next? (I'm assuming that completion isn't sent until after the message is persisted.) As far as I can tell, the client will have to establish a new session and is never going to get completion of the send command, so it's going to have to assume the send failed and retry it. Section 3.2.4 of the AMQP 0-10 spec implies that brokers are expected to recognize the resend and not create a duplicate message, is that correct?

*         What happens if the send above is in an internal transaction? The sent message isn't visible in the queue until the transaction is committed, but after the broker restarts, the transaction is gone. Does section 3.2.4 apply here also?

*         Speaking of transactions, what happens if a persistent message is accepted in an internal transaction but the broker restarts before the transaction is committed or rolled back? My guess is that the message in the store is not modified or removed until the commit, so when the broker restarts, the message reappears in the queue as though a rollback had occurred.

*         The spec points out that sending a persistent message to a nonpersistent queue makes no sense, but that's not the same as forbidding it. How does Qpid treat this case?

*         If one persistent message is delivered to multiple persistent queues, is it persisted as one message with multiple mappings, or multiple messages with one mapping each?

If anyone would like to see the entire test plan, just let me know.

Thanks!

--James B.

Re: Qpid C++ broker behavior questions

[Gordon Sim <gs...@redhat.com>]

Apologies for delayed response, I was away last week and am still 
dealing with some backlog in my inbox....

On 09/23/2009 02:33 AM, James Birdsall wrote:
> I'm doing the test plan for the persistence provider that Steve Huston is working on, and I've hit a number of points where I'm not clear on what the expected behavior is. If someone could point me in the right direction, it would be much appreciated!
>
>
> *         If a client sends a persistent message to a persistent queue and the broker restarts before the client receives completion of the send, what happens next? (I'm assuming that completion isn't sent until after the message is persisted.) As far as I can tell, the client will have to establish a new session and is never going to get completion of the send command, so it's going to have to assume the send failed and retry it. Section 3.2.4 of the AMQP 0-10 spec implies that brokers are expected to recognize the resend and not create a duplicate message, is that correct?

The connection is lost and with it the session state. The client could 
resend in-doubt messages but these could well result in duplicates that 
for the time being would have to be detected by recipients (the broker 
will not detect them).

The session resume described in 3.2.4 is really only applicable if the 
state of the session is still available for both client and server ends, 
which in the case of an unclustered broker restarting is unlikely to be 
the case. We don't currently support that anyway.

> *         What happens if the send above is in an internal transaction? The sent message isn't visible in the queue until the transaction is committed, but after the broker restarts, the transaction is gone. Does section 3.2.4 apply here also?

If the broker restarts it will have lost all session state and therefore 
3.2.4 does not (in my reading of that section) apply.

> *         Speaking of transactions, what happens if a persistent message is accepted in an internal transaction but the broker restarts before the transaction is committed or rolled back? My guess is that the message in the store is not modified or removed until the commit, so when the broker restarts, the message reappears in the queue as though a rollback had occurred.

Yes, that's correct.

> *         The spec points out that sending a persistent message to a nonpersistent queue makes no sense, but that's not the same as forbidding it. How does Qpid treat this case?

It ignores the delivery-mode of the message if the queue is not durable.

> *         If one persistent message is delivered to multiple persistent queues, is it persisted as one message with multiple mappings, or multiple messages with one mapping each?

That sort of depends on the store implementation, but frankly the store 
interface has grown all sorts of warts as the inadequacies of the 
initial version were uncovered.

The broker should call enqueue() for every queue the message is enqueued 
on. The 'journal' based store plugin that exists at present stores each 
message separately in each respective queue journal, but in theory a 
store could simply store the message once and record the queues it was 
enqueued on.

> If anyone would like to see the entire test plan, just let me know.
>
> Thanks!
>
> --James B.
>
>


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org