qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: messaging API Connection open but Session in error
Date Wed, 25 Jun 2014 15:04:55 GMT
On 06/09/2014 08:05 PM, CLIVE wrote:
> - Inconsistent behavior of Sender when Broker not connected. When
> sending a message an Exception occurs, as no connection, but messages
> are still placed in outbound queue up until the Sender is flushed
> ('window < Capacity/4' , not sure where the 4 comes from). At this point
> any further sent messages still cause an exception, but messages do not
> get placed in the outbound queue. Varying the capacity varies when this
> occurs and so doesn't seem correct.

I've checked in a fix for this. The behaviour now is that if 
disconnected and a flush() or sync() (which are used to free up 
capacity) fails, the send will ignore that and try to continue with the 
send anyway providing there is capacity. This means of course that the 
send will still fail with a TransportFailure, but the message will 
always be added to the replay buffer if there is any remaining capacity.

If there is no capacity remaining (and we can't free any using sync() or 
flush() due to being disconnected), the behaviour depends on whether 
auto-reconnect is in use on the connection.

If it is, the TransportFailure will be thrown as before, meaning the 
auto-reconnect will kick in and essentially block the call until we can 
connect and sync(), freeing capacity for the send.

If auto-reconnect is not in use, then an OutOfCapacity is thrown rather 
than the TransportFailure. This allows the application handling the 
exception to differentiate between the case where the message does need 
to be explicitly resent and the case where it has already been queued 
for replay on reconnection.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message