[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Problem with socket reconnects
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?
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 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:
> > Hi Marcel,
> > 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.
> > Thanks,
> > Steve
> the problem is that you have not specified a well known
> public session id (for example 'joe/1'), as this is specified in