Plana, Richard schrieb:
So far, so good. You also need to tell mod_proxy_balancer,
what the
name of the URL parameter resp. Cookie is, which carries
the routing
information. I forgot about that (in mod_jk it is
automatically the
right for Java App Servers, mod_proxy is more flexible and
you need
to set it).

So add "stickysession=JSESSIONID|jsessionid" at the end of the ProxyPass line. See also the mod_proxy docs page, look out for stcikysession.
Tried that after you mentioned it, but no, httpd still shifts my access from one node to the other (and I lose my session
info). I even
tried the plain example on the docs page (no jvmRoute
info). Still no go.
Suggestions? Ideas?
Is that related to the error message you posted in the parallel discussion thread, i.e. are the two things happening at the same time? If so I would say a worker went into error state because of this (and it keeps that state for some time) and all requests have been rerouted to the other worker.

Good catch, but no, it doesn't seem like the two are related.
Unfortunately, I've to deal with them at the same time. The timeout that
happens on the other thread usually doesn't happen for a long time
(minutes). The events I'm experiencing here happen within a matter of
seconds.

Basically, I open a user session and go through various pages on my app.
After a couple of clicks, the app just brings me back to the start page.
I'm monitoring logs from both sides and I see that as soon as it comes
back in error and brings me to the login page, activity switches to the
other app server (the one that I wasn't using prior to the problem).

Just to make sure: what kind of error do you mean here? The httpd timeout and that is not the only source of lost stickyness, or some application error? If it is an application error, it would not be too strange, that the application invalidates the session.

Good catch, though. I've added "nofailover=On" to the ProxyPass line and
tested it. Again, in the middle of the session, it switched to another
node and I lost my session again. So not likely an error-induced
failover.

If you want to debug a little more: In Tomcat you can add a %S to your log pattern, which will log the session id. In httpd you can log the Set-Cookie outgoing header "%{Set-Cookie}o" and the JSESSIONID cookie "%{JSESSIONID}C". If you are not using cookies, you can of course see the jsessionid path parameter dircetly in the logged URL.

Regards,

Rainer

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to