-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
George,
On 2/16/2010 5:14 PM, George Baxter wrote:
> Yes, the getHeaders("cookie") returns what seems to be a valid set of
> cookies, thus we're not losing them in any of the proxies we might
> have set up.
Good to know. But this means that Tomcat is ignoring them, then, right?
How many "Cookie" headers do you get? I believe Tomcat looks for any
Cookies with the name JSESSIONID and then loops through each of them
until it finds a valid session id for the webapp servicing the request.
So, if there's a valid cookie in there for the JSESSIONID, Tomcat should
use it.
> We get this problem in all sorts of browsers (FF, Safari, IE).
We had a problem like this, but we were deploying two webapps within the
same URL space which resulted in two JSESSIONID cookies being sent by
the browser. We had a third webapp, which didn't use sessions directly,
but used the JSESSIONID passed-in from the browser to to a loop-back
call to one of the other webapps with a ";jsessionid=" in the URL in
order to masquerade as the remote user. Since the 3rd webapp couldn't
verify which of the two JSESSIONID cookies to use, it had to guess and
it often guessed incorrectly. The solution was to separate the two
primary webapps into separate URL spaces.
Perhaps you have something weird like this going on?
> The thing that really bugs me is the inconsistency. It's almost as
> if there were a race condition going on, but the request is basically
> single threaded, isn't it? My only fear is some parser used in the
> tomcat code is being used in a non-thread safe manner, but then
> *everybody* would be having this problem, neh?
Most likely: there are many Tomcat users out there who use cookie-based
session tracking without any of these problems. You are likely to be
unique in this regard :(
> I'm finding out about the connectors, but we may not be using any as
> :
>
> Jan 28, 2010 6:52:56 PM org.apache.catalina.core.AprLifecycleListener
> init INFO: The APR based Apache Tomcat Native library which allows
> optimal performance in production environments was not found on the
> java.library.path: /dist/sfsite/obj
This just means (note the "INFO" log level) that APR is not being used,
but was requested by the presence of the AprLifecycleListener in
server.xml. If you aren't /trying/ to use APR, you can ignore this INFO
message: Tomcat will default to the pure-Java <Connectors> if APR is not
available.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkt7HAsACgkQ9CaO5/Lv0PDLQACfYbDz3nbdGN9r0/hQMcpocVlO
frcAoIaWRPhWe560mlKcDZdwbiNKStz+
=7x53
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
