[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Problem with socket reconnects
Steve Mentzer wrote:
Thanks Marcel. It works when I do as you indicate. The fact that it seemed
to work with the released version and under IOR misled me, it appears.
Strangely, it works now even though I don't explicitly set the session to
be persistent. Is that the default setting?
Setting the subscription to persistent implicitly sets
the session to be persistent.
I'm confused about the purpose of the ping between the client and server.
As was mentioned a few months back on this list, it doesn't reset the
session timeout. Is it only intended to detect a failed endpoint?
The session timeout stands for client inactivity.
Imagine a homebanking session, the low level ping is OK but
the user has left the computer. After some minutes the bank
will throw you out.
The low level ping checks the physical/application level connection
and automatically tries to reconnect on failure.
You can call
to refresh the session.
The reason I ask is that in order to keep clients that only subscribe to
topics from being disconnected we have to set the session timeout to 0.
But if we also set the session to be persistent, the session object will
only be destroyed if the client issues a disconnect. If the client never
does (e.g. due to a crash) and never reconnects, its abandoned session
will persist forever.
If the ping did reset the session timeout we'd be able to set it to a high
value (weeks) and be confident that active, persistent sessions wouldn't
be destroyed. But that doesn't work in the case of a failsafe client
because we are instructed that the server callback ping must be turned
off. Is that necessary or can we use a high retry count?
--- Marcel Ruff <mr at marcelruff.info> wrote:
Steve Mentzer wrote:
I am using the latest xmlBlaster 0.91 from CVS (er, SVN) and am
experiencing a new problem with the socket protocol.
The problem is if I connect a client to the xmlBlaster server (again,
using the socket protocol), subscribe to a topic, then shut down and
restart xmlBlaster (but not the client), the client doesn't properly
restablish its connection when xmlBlaster restarts. It no longer
messages published to its subscribed topic. From what I can tell from
trace, it's getting a new session ID (e.g. originally -2 but after
xmlBlaster restarts it's -4) which I don't think should happen. It
properly with the IOR protocol and it worked okay in the released
Let me know if you need more data.
the problem is that you have not specified a well known
public session id (for example 'joe/1'), as this is specified in