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, otherwise something might cause the client to try to reuse the
channel while there are still messages in transit for it. I think the
time to do this is when the use-count is going to zero - depending on
how the smart pointer works this will either be just in time and the
channel can be marked as a zombie, or just too late and you'll need to
insert a stand-in zombie.
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?
James
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
