On Mon, Feb 25, 2008 at 02:48:33PM +0100, Marcel Ruff wrote: > David Kerry wrote: > >Hello All, > > > >I'm seeing some odd behaviour on one of my clients here and I'm > >not sure if it's a bug, feature, or configuration problem. Client > >and server are running the 1.6.2 version of code. > > > Hi David, > > 1. Why is secretSessionId invalid? > We would need to see the server log for this, possibly the session > timed out. > > 2. Is the client connecting in fail safe mode? > o With public session ID > 0: -session.name spiderman_test/1 > o -dispatch/callback/retries -1 > > To detect going DEAD you can register > xmlBlasterAccess.registerConnectionListener() > and react Kerry-like (see xmlBlaster/demo/HelloWorld4.java). > > Still it would be good to know why the secret sessionId got invalid. > > best regards > Marcel, Michele
Hi Marcel, Well, I figured this out - it was a bit of a misunderstanding on the session timeout parameter. I didn't look close enough and thought it was in seconds instead of milliseconds. Thus, my client's sessions kept timing out on the server side much too fast! The client wasn't connecting in fail safe mode, and I was using a connection listener to monitor the connection, which helped my figure out what was going on. However, the client behaviour when the server times out the session is still a little off, I believe. What I see happening is the server kills the client session (fine), but the client doesn't notice that fact until it tries to use the connection (ie: publish), even though it has a connection-ping setup for every 10 seconds. Once the publish happens, the client goes 'oh, my connection is dead' and then starts queuing messages. At this point, however, the client never goes into a polling mode and the only way to re-establish communications is to do a disconnect(), re-instatiate a new XmlBlasterAccess and do another connect(). This whole process also has the side-effect of erasing all the queued messages. If I try to simply call connect() again, I get an exception stating "connect() rejected, you are connected already, please check your code". My way of working around this for now is to create yet another queue, in my application that keeps a copy of the saved messages until a connection is re-established after which it puts them back in the xmlblaster queue for publishing. This works, but it's, well, ugly. Is this the intended client behaviour in this situation? Keep in mind that I'm not concerned about subscriptions and incoming messages to this client, if that makes a difference. -- David Kerry
