On 03/20/2012 09:43 PM, Jeff Armstrong wrote:
I have a queue with REJECT policy and a max count. If I connect a sender client and fill the queue to the max size, the broker seems to destroy the session. Using qpid-tool I can see that the session is gone, though the connection is still there. In the sender client session.isValid() still returns true. If I then connect a receiving client to drain the queues, the sender still fails to send messages to the broker unless I close the session and re-open it. This seems like really weird behaviour to have your session deleted because you hit a max count and then not being able to tell from the sender that this has happened.
Yes, it is annoying. The AMQP 0-10 (and earlier) specification(s) state that when an 'exception' indication is sent on a session, the session must then be terminated. What you are seeing is that fact bubbling up to the API.
The qpid::client::Session::isValid() at present only tests whether the 'handle' refers to an actual session object and doesn't take into account the state of that session. Again, I can see that is not intuitive. There isn't an ideal way to workaround that either. You can call flush() on the session which has minimal effect but would act as a test that it is active (you would need to catch an exception in the event that it was not).
I would like to revise the general lifecycle of sessions in the case of exceptional conditions, but any change would almost certainly be in the messaging API only as the session abstraction there is not tied so directly to an AMQP 0-10 session.
I could modify the qpid::client::Session::isValid() method or expose an additional method, in order to make testing full 'validity' simpler. Not sure how much value that would be to you however.
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
