Re: [xmlblaster] Client connection not being restored properly?

[David Kerry <xml at navahonetworks.com>]

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
>