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, just need to get some
time to work on it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
