Re: [xmlblaster] Problem with socket reconnects

[Marcel Ruff <mr at marcelruff.info>]

Steve Mentzer wrote:
> > > 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!

Your use case sounds reasonable, i have added a ConnectQos flag
to switch on an automatical refresh from client side:

  ConnectQos qos = new ConnectQos(glob);
  qos.setRefreshSession(true);
  ...


You can play with it (newest code from subversion):

  java org.xmlBlaster.Main


  java javaclients.HelloWorldSubscribe
                       -session.timeout 3000
                       -connect/qos/sessionRefresh true
                       -dispatch/connection/pingInterval 1300

In the above example the subscriber client would be logged out after 3 seconds
but setting "-connect/qos/sessionRefresh true" prevents it,

enjoy

Marcel

> 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


--
http://www.xmlBlaster.org