Re: [xmlblaster] Problem with socket reconnects

[Steve Mentzer <sgmentzer at yahoo.com>]

> > 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?
> 
> Yes.
> 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.

That's true in the case of a web browser, where the bank has no control
over the client. But with xmlBlaster we control both client and server, so
if we want to timeout an inactive client we'll build that into the client.
 
> The low level ping checks the physical/application level connection
> and automatically tries to reconnect on failure.
> 
> You can call
>    xmlBlasterAccess.refreshSession();
> to refresh the session.
> 

I looked at this and it just does a get() with the special "__refresh"
oid. Therefore, in order to keep the connection alive every client needs
to call this function periodically.

If you can't tell, I'm lobbying to have the ping reset the session
timeout. It just doesn't make sense for it not to, especially given that
when the server times out an active client session, the client
automatically reconnects!

Steve

--- Marcel Ruff <mr at marcelruff.info> wrote:

> 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?
> 
> 
> > 
> > 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?
> 
> Yes.
> 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
>    xmlBlasterAccess.refreshSession();
> to refresh the session.
> 
> regards
> 
> Marcel
> 
> > 
> > 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?
> > 
> > Thanks,
> > 
> > Steve
> > 
> > --- 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
> >>
> >>receives
> >>
> >>>messages published to its subscribed topic. From what I can tell from
> >>
> >>the
> >>
> >>>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
> >>
> >>works
> >>
> >>>properly with the IOR protocol and it worked okay in the released
> >>
> >>0.91.
> >>
> >>>Let me know if you need more data.
> >>>
> >>>Thanks,
> >>>
> >>>Steve
> >>>
> >>>
> >>
> >>Hi,
> >>
> >>the problem is that you have not specified a well known
> >>public session id (for example 'joe/1'), as this is specified in
> >>
> >>
> > 
> >
>
http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.persistence.session.html
> > 
> >
>
http://www.xmlblaster.org/xmlBlaster/doc/requirements/client.failsafe.html#naming
> > 
> >>regards,
> >>
> >>Marcel
> >>
> >>-- 
> >>http://www.xmlBlaster.org
> >>
> > 
> > 
> > 
> 
> 
> -- 
> http://www.xmlBlaster.org
>