qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: [c++]: race condition in client when handling session close due to execution.exception
Date Mon, 06 Apr 2009 09:29:17 GMT
James Mansion wrote:
> Gordon Sim wrote:
>> However, following the execution.exception is the session.detach as 
>> required by the AMQP 0-10 spec. If the session goes out of scope 
>> before this is handled, then the whole connection ends up being 
>> destroyed due to the NotAttachedException thrown.
> To me that suggests that some representation of a Channel object *must* 
> live on until the client and server have both agreed that it has been 
> closed, 

Yes, I agree. It is logically incorrect to treat a session that the 
application has let go out of scope as detached without ensuring that 
the server has been informed of the detachment[1].

> otherwise something might cause the client to try to reuse the 
> channel while there are still messages in transit for it. 

True. The current API doesn't yet support reusing channels on a given 
connection, though[2].

>> It does mean that the client would not correctly handle an erroneous 
>> attempt by the broker to send frames on a session that has genuinely 
>> been detached. That isn't as serious in my view and seems like a 
>> worthwhile trade for getting the issue describe in the jira resolved.
> Surely the problem is also that the broker has (or will shortly) send 
> frames that the protocol requires - that's hardly erroneous?

After sending an execution.exception, the broker will only send the 
detach frame. The current client implementation takes the detach as 
implied by the exception and marks the session as detached on handling 
the exception. Therefore the detach frame will not have actually have 
any effect. Dropping it is in my view preferable to throwing an 
exception, which will result in the whole connection being lost.

Correcting the design is even better of course. My proposed patch 
doesn't attempt to do that, it is just a simple fix for an immediate and 
real problem. However I've created a couple of Jiras for these other 
issues if anyone wants to take them on.

[1] https://issues.apache.org/jira/browse/QPID-1789
[2] https://issues.apache.org/jira/browse/QPID-1788

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

View raw message