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
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
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
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
Hi David,
fail safe mode should also set a positive session id,
like this the client queue is found again on restart and
you don't need another queue to store the entries.
Something like
java -Dcom.sun.management.jmxremote javaclients.HelloWorldSubscribe
-session.name subscriber/1
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,
David Kerry wrote:
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
On Wed, Feb 27, 2008 at 06:28:59PM +0100, Marcel Ruff wrote:
snip
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
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
