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.