Re: Qpid destroys session after max queue size reached
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(); 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(). - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid destroys session after max queue size reached
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
Re: Qpid destroys session after max queue size reached
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.**orgusers-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid destroys session after max queue size reached
For my safe, since my app is multithreaded, the best I can do is to serialize access to the same Sender/Session object on each send() call and check for errors to try to handle such situation. On Thu, Mar 22, 2012 at 14:32, Gordon Sim g...@redhat.com wrote: On 03/22/2012 04:58 PM, Virgilio Fornazin wrote: 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 ? Not terribly well at present is the honest answer. This is something I would like to revisit. In the messaging API we could probably shield the application from the underlying loss of AMQP session, or at least ensure that their session object can continue to be used. All messages that the broker received before hitting the limit will be on the queue. If they were durable messages, they may not all have been written to disk, but the loss of session won't interfere with that. The problem is how the application can infer this from the messaging API. Generally you would use the unsettled count on the sender to determine how many of your sent messages remained in doubt. However that is only periodically updated so it often won't be up to date when a session error occurs. Again that is something we could change, and have the broker issue a completion before sending any exception and ending the session. I do have a JIRA open for this: https://issues.apache.org/** jira/browse/QPID-3179 https://issues.apache.org/jira/browse/QPID-3179, just need to get some time to work on it. --**--**- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**orgusers-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid destroys session after max queue size reached
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
