On 03/22/2012 02:23 PM, Alan Conway wrote:
On 03/21/2012 09:22 AM, Gordon Sim wrote:
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).
There are 2 methods to check if a session was terminated by an error:
/**
* @returns true if the session has been rendered invalid by some
* exception, false if it is valid for use.
*/
QPID_MESSAGING_EXTERN bool hasError();
/**
* If the session has been rendered invalid by some exception,
* this method will result in that exception being thrown on
* calling this method.
*/
QPID_MESSAGING_EXTERN void checkError();
Unfortunately those are only available on qpid::messaging::Session, not
the older qpid::client::Session.
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.
isValid() is inherited from class Handle so I don't think we should put
additional semantics into it.
It's actually redundant since isNull() does the same test inverted and
is IMO more clearly named. Maybe we should deprecate isValid().
Again I think that is true for the messaging API, not the older 'client'
API.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
