Hi Marcel, In fact, that is what I have done for now (set session to unlimited).
The only reason it has been an issue is because the default client session timeout is 24 hours and in some cases, I forgot to override the default in some of our low-traffic situations. Oops. If I were to file some bugs against this it would be: 1) What is the purpose of the session timing out on the server side when the client is still connected/alive (as far as a network connection is concerned, eg - ping requests are still being answered by the client)? If the client's alive, keep the session alive and just eliminate the server-side session timeout perhaps? 2) If the client reaches the 'DEAD' state, it shouldn't accept and queue more messages for publishing that it will never/can never publish. -- David Kerry On Thu, Apr 03, 2008 at 09:32:41AM +0200, Marcel Ruff wrote: > Hi David, > > I think your solution is to keep the server session alive by setting > the session to unlimited. > > Further Notes: > You could call xmlBlasterAccess.refreshSession() > to refresh the server side session (but this can fail if the network is > broken and the refresh is not reaching the server in time). > > If you don't want to use an unlimited server session you need to > destroy the XmlBlasterAccess instance (without deleting the client queue > entries) > when going to DEAD (xmlBlasterAccess.disconnect(disConnectQos)). > Use a disConnectQos.clearClientQueue(false) to keep the entries. > Re-establish the connection with a new XmlBlasterAccess instance > which then sends the existing queue entries. > However - this will, i think, not work if you use a RAM,1.0 queue (no DB). > > As said in the last mail, XmlBlasterAccess behavior is fishy after going > to DEAD, > which needs to be fixed by us. > We more clearly need to invalidate the XmlBlasterAccess instance in this > case. > > And finally: > If your scenario is a use case which we should support we > can think of changing the client library behavior so that a > server session timeout triggers a POLLING (and not a DEAD) > which would solve your case. Is there any logical reason > to keep the to-DEAD pattern (Michele?) > > regards > Marcel > > > David Kerry wrote: > >On Wed, Apr 02, 2008 at 07:42:54PM +0200, Marcel Ruff wrote: > > > >>Hi David, > >> > >>if the server side session times out the expected behavior is > >>that the client goes to dead (what you client seem to do). > >>That your client recovers from DEAD is not intended > >>and is considered a bug, see > >>http://www.xmlblaster.org/xmlBlaster/doc/requirements/client.failsafe.html#failsave > >>The transition (9) and (8) should not happen. > >> > >> > >>Thanks for reporting > >>best regards > >>Marcel > >> > > > >Hi Marcel, > > > >Whoops! > > > >Then I guess the original issue is still outstanding then. > > > >If my client goes from ALIVE->DEAD, simply because of a session > >timeout on the server side, what are my options on the client > >side to reconnect gracefully and to prevent the loss of the > >messages still queued on the client side? > > > >The client still happily accepts messages for queueing even > >though the connection state is DEAD and returns no errors. > > > > -- > Marcel Ruff > http://www.xmlBlaster.org > http://watchee.net > Phone: +49 7551 309371 >
