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