Martin Johnson wrote:
Hi Marcel
How would I achieve this use case.
A client (socket) using a persistent connection and persistent
subscription disconnects from the server gracefully.
Hi Martin,
if you call on client side:
xmlBlasterAccess.leaveServer(null) ; // instead of
xmlBlasterAccess.disconnect(...)
the client side resources are freed but the server maintains the session
and
queues the subscribed messages.
The client should use a positive public session id like:
"client/joe/session/1"
and can reconnect to this session on restart (to access the filled
callback queue).
Further it should tell the xmlBlaster server on lost callback ping to
retry, this is a command line example:
java javaclients.HelloWorldSubscribe -session.name joe/5 -oid Hello
-dispatch/callback/retries -1 -persistentSubscribe true
You should set -persistentSubscribe to true as well. In this case even
the xmlBlaster server
may go down and on restart immediately collects messages for the
subscriber (even if the subscriber
arrives a day later).
Like this no messages are ever lost.
What you describe is a very common use case used
most time with xmlBlaster and works very reliable,
regards
Marcel
During this periond when the client is not available (ie shutdown for
some maintenance) the server continues maintaining session and
subscription queue. The client is then started again and connects to
same sessionid and recv's messages published during period of downtime.
I have been trying with
<qos>
<deleteSubjectQueue>false</deleteSubjectQueue>
<clearSessions>false</clearSessions>
</qos>
When calling disconnect()
Without much luck.
Regards
Martin
--
Marcel Ruff
http://www.xmlBlaster.org
