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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org