what you're seeing is correct.
the server did fail over, and by changing the session id, it ensures
that it does not do fail back
Filip
Roy McMorran wrote:
Hello all,
I've built a very simple 2-member Tomcat cluster for testing, but I am
unable to get the session replication quite right.
To stick with the analogy:
Your session's baby part is: FEBA6A8127A69079C79B7A641158CE20 and
that remains the same if with daddy or mommy.
Your session's daddy part is: itchy
and
Your session's mommy part is: scratchy
Enjoy them :)
János
On Apr 3, 2009, at 5:32 PM, Roy McMorran wrote:
Hi Jorge, thanks for the reply.
Actually no, these are the access logs from the Tomcat cluster members;
you can view the corresponding AccessLogValve entries in the server.xml
files referenced below.
I included those logs for illustration, but I have confirmed that those
are the actual
Roy McMorran wrote:
Hi Jorge, thanks for the reply.
Actually no, these are the access logs from the Tomcat cluster members;
you can view the corresponding AccessLogValve entries in the server.xml
files referenced below.
I included those logs for illustration, but I have confirmed that
Mark Thomas wrote:
Nope. The job of that valve is to change the route - exactly what you
are seeing.
Thanks Mark,
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Thanks,
Roy
--
Roy McMorran
Systems Administrator
Roy McMorran wrote:
Mark Thomas wrote:
Nope. The job of that valve is to change the route - exactly what you
are seeing.
Thanks Mark,
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Yes
Mark
Mark Thomas wrote:
Roy McMorran wrote:
Thanks Mark,
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Yes
Mark
Interesting. I am certain I saw the other behavior (both parts of the
session ID were
Mark Thomas wrote:
Roy McMorran wrote:
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Yes
OK, please bear with me here, I may be just showing my ignorance with
respect to Tomcat and web applications in
From: Roy McMorran [mailto:mcmor...@mdibl.org]
Subject: Re: Session Replication in Cluster
If the session ID changes from ABC123.node1 to ABC123.node2, then
you will start a new session at the browser.
No, you get a new *cookie* at the browser; the session is something only the
server has
On Apr 3, 2009, at 3:31 PM, Roy McMorran wrote:
Mark Thomas wrote:
Roy McMorran wrote:
Is it the expected behavior then, that the 2nd part of the session
ID
changes after a failover, and a new cookie is set?
Yes
OK, please bear with me here, I may be just showing my ignorance
Caldarale, Charles R wrote:
From: Roy McMorran [mailto:mcmor...@mdibl.org]
Subject: Re: Session Replication in Cluster
If the session ID changes from ABC123.node1 to ABC123.node2, then
you will start a new session at the browser.
No, you get a new *cookie* at the browser; the session
János Löbb wrote:
If You look the values created by the session earlier with
...node1, than You will see the same values after fail over with
...node2. A new session would not know about them.
To verify it You can use the supplied SessionExmaple webapp.
It is like passing a baby among
János Löbb wrote:
If You look the values created by the session earlier with
...node1, than You will see the same values after fail over with
...node2. A new session would not know about them.
To verify it You can use the supplied SessionExmaple webapp.
OK, trying that.
So, using an
Roy McMorran wrote:
János Löbb wrote:
If You look the values created by the session earlier with
...node1, than You will see the same values after fail over with
...node2. A new session would not know about them.
To verify it You can use the supplied SessionExmaple webapp.
OK, trying
Are your logs Apache logs? Mod_jk logs?
If it is Apache, the question would probably better answer in the Apache
mailing list.
Anyway, What does your LogFormat string looks like?
I bet what you see in the logs is the concatenation of the session ID
and the worker name. I doubt two servers
15 matches
Mail list logo
