On Wed, Feb 27, 2008 at 06:28:59PM +0100, Marcel Ruff wrote:
<snip>
My way of working around this for now is to create yet another queue,
in my application that keeps a copy of the saved messages until a
connection is re-established after which it puts them back in the
xmlblaster queue for publishing.
This works, but it's, well, ugly. Is this the intended client behaviour
in this situation? Keep in mind that I'm not concerned about subscriptions
and incoming messages to this client, if that makes a difference.
Hi David,
what about starting the client in fail safe mode?
Like this the client retries to establish a connection and sends the
queued messages on reconnect,
regards,
Marcel
Hi Marcel,
I think I was mistaken. I think I am connecting in fail-safe mode, if
'fail-safe' mode means setting up the connection reconnect/ping/retry
values. I am not specifying an explicit session id, however (I get a
negative id back upon connect).
For reference, here are the connect properties I'm using:
protocol=SOCKET
dispatch/connection/pingInterval=30000
dispatch/connection/retries=-1
dispatch/connection/delay=5000
dispatch/connection/plugin/socket/port=7607
dispatch/connection/plugin/socket/hostname=....
queue/connection/defaultPlugin=RAM,1.0
The rest are whatever defaults that xmlblaster client provides.
>From reading the reference docs, I think this actually does enable failsafe
mode, correct?