[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Client connection not being restored properly?
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
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
> 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
> 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?)
> 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
> >>The transition (9) and (8) should not happen.
> >>Thanks for reporting
> >>best regards
> >Hi Marcel,
> >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
> Phone: +49 7551 309371