Gordon If I have the Sender Capacity to 1000 Messages per example, and the queue has a limit of 800 Messages, and after I send 801 messages, the session is closed after the exception while trying to delivery the message to the queue.
But the 800 messages sent previously are guaranteed to be delivered and stay in queue, since they couldn't be acknowledged by the broker after the session is terminated? How the API deals with this situation ? On Thu, Mar 22, 2012 at 11:27, Gordon Sim <g...@redhat.com> wrote: > 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<users-unsubscr...@qpid.apache.org> > For additional commands, e-mail: users-h...@qpid.apache.org > >
