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 <[email protected]> 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: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
