I find that despite there being an incoming JSESSIONID cookie, sometimes this doesn't make it into the requests Cookies. I've confirmed this by trapping the case in my servlet filter, and then examining the request. In this case I can see the cookie header, but the cookies are empty. Some specifics - I'm using JBoss 4.0.1sp1, which has Tomcat 5.0 embedded. The use of the session is in a servlet filter for security. I store a JAAS subject on the session in my login form, and I test the existence in the filter. The pages generated by the application then make many other requests. IE correctly sends the cookie in the requests, but sometimes, perhaps one in five or one in ten requests, the cookie is ignored as stated in the first paragraph. I access the sessions using synchronized blocks to avoid multiple simul updates. I tried adding a sync on the doFilter method on the off chance that there was a session issue (although, as noted above, the issue appears to be due to the cookies).
I am sorry, but I simply do not believe you. Objects used for reading and parsing the requests are per thread, and as a result are fully independent (this includes headers and cookies). If you believe there's an issue, you'll have to investigate it yourself, and submit a fix (or at least find out what goes wrong inside the Tomcat code, and where).
I will do more investigation. But "I don't believe you" isn't a particularly reasonable response. It may be the fault is outside of Tomcat, but it really is hard to argue with what I saw in the debugger. If I had a dollar for every time I thought that, and later found the problem I could probably retire.
OK, I've done more investigation. I believe what's happening is that the unprocessed flag in the cookies object is getting set to false before the headers are all available. Here's why: I put a breakpoint in my servlet filter just before I get the session. I ask for the cookies and I break if cookies returns null. Then I go into the data structure and look at the CoyoteRequest object. The Cookies object has unprocessed=false and no cookies, but the headers include a cookie header. I reset unprocessed to true, then I reaccess Cookies and the JSESSIONID cookie appears. More data: I put a breakpoint in the cookie parser and it never failed to find the header. So what I'm wondering is if there is a case where parsing might be bypassed? For example, it looks like the cookies are normally processed on object creation and then if recycle is called. Could the headers sometimes be getting set without calling recycle? The other bug I'm seeing is that sometimes the scheme isn't set on the request. request.getScheme returns null (which breaks redirect).
This does not make any sense at all, especially: (In reply to comment #3) > unprocessed flag in the cookies object is getting set to false before the > headers are all available The first thing which occurs is parsing the headers. If cookie parsing is done "before", then you are looking at improper access to the container objects. Try to enable the security manager to get some NPEs to reveal them. I don't know where your problem is, but all I know is that it is not in Tomcat. Please do not reopen the report.