tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kulessa <>
Subject Re: HttpServletRequest - getHeaders() vs getCookies()
Date Wed, 09 Jul 2014 08:51:00 GMT

I had a look at the documentation and the tomcat source to get a better 
of what the '|org.apache.catalina.connector.RECYCLE_FACADE' parameter 
actually does.|

I have seen that Tomcat objects like Cookies, Request etc. are designed 
to be reusable.
What I currently do not understand is: In which scenario and what 
context are they going to be reused?
I see there are Endpoints classes (like NIOEndpoint) which are used to 
process the different requests.
This seems to be the most likely entry point into the scenario.

Maybe somebody can provide some general outline of how requests and the 
reusing of the object
actually works together? Is there some kind of relation to the IP of an 
incoming request?

In our code we hold a reference to the httpSession outside of the 
request (in a application scoped map).
We use this session object to read the SessionId, to invalidate or to 
adjust the session timeout from
outside a client request.

I finally received the logs where the session itself was created:
Basically there is some communication ongoing between client and server,
then the server receives an unexpected command and decides to invalidate 
the session because of this.
Later another command of the client with the old cookie arrives and is 
rejected by our server.
After this any other request coming from the same IP fails.
As mentioned in the logs we see the httpHeader that does contain a 
cookie with a different value,
but the getCookies() method always provides the cookie value of the 
'original session'.

Around the same time when the original session was still alive I found 
an error message in the Catalina log:

... org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
SEVERE: null
java.lang.IllegalStateException: Calling [asyncPostProcess()] is not 
valid for a request with Async state [STARTED]
     at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
     at java.util.concurrent.ThreadPoolExecutor$ Source)
     at Source)

I am not sure whether this is somewhat related to the problem scenario, 
but at least this looks like
something that should not happen.

Simon Kulessa

Am 08.07.2014 11:35, schrieb Simon Kulessa:
> Hi Konstantin,
> thanks for you answer.
> Am 08.07.2014 10:22, schrieb Konstantin Kolinko:
>> 2014-07-08 11:48 GMT+04:00 Simon Kulessa <>:
>>> Hi,
>>> we are running a server on Apache Tomcat 7.0.29 with usage of the
>>> servlet-api 3.0.1.
>> 1. The current version is 7.0.54
> We updated to this version now, but since our server is already 
> running at the customer
> exchanging the tomcat might not be a option for now.
> Before we can do this, we should at least have an idea about where the 
> problem is coming from.
>> 2. What is "3.0.1". You may use any servlet-api jar when compiling,
>> but at run time you must use the one that comes with Tomcat.
> Ok. So correct would be we compile against the servlet-api 3.0.1 
> (maven dependecy groupId=javax.servlet, artifactId=javax.servlet-api)
> and use the one from tomcat in production. The tomcat version seems to 
> provide a different version 3.0.FR (taken from the manifest).
> Could this be an issue?
>>>  From one of our customers we received a bug report that in certain 
>>> times an
>>> IOException (Stream is closed)
>>> is thrown while reading the data from a HttpServletRequest.
>>> After some investigation we added some logging and now we see the 
>>> following
>>> information:
>>> First we logged the headers of the http request (by using
>>> HttpServletRequest#getHeaders()) and
>>> we see a JSESSIONID cookie with a value of 'A'.
>>> After this we use HttpServletRequest#getCookies() to log the cookies as
>>> well.
>>> Here we only see a JSESSIONID cookie with a value of 'B'.
>>> The requested sessionId from the servletRequest has value 'A' as well.
>>> My question is: How can this be?
>>> How is it possible that getCookies returns a cookie that is not 
>>> defined in
>>> the header of the http request?
>>> Where does this cookie come from? And were did the cookie go that was
>>> defined in the header?
>> 3. Usually that is caused by bad programming in a web application,
>> when newbie programmers share "request" object between requests. The
>> unexpected "Stream is closed" issues are also symptoms of that.
>> An example:
> Currently I see nothing in our code that indicates this, but I will 
> have another look at that,
> since this seems to be the most likely explanation.
>> 4. I think getHeaders() may return some garbage for Cookie header (as
>> the value may be corrupted when parsing the value into a cookie),  but
>> it should not contain a value from different user.
> Currently I can not verify whether the cookie value of 'B' is linked 
> to some other user
> (I am still missing some log files from the previous days).
> For now I can only say it does not seem to be the case, that the 
> cookie value is linked
> to another user.
> What I can see is that the problem seems to be reoccurring. All the 
> requests were
> the Exception actually happens are being send from the same IP. The 
> cookie value in
> the header is always different, while the cookie value returned from 
> getCookies() is
> always the same.
>> 5. A browser may send several JSESSIONID cookies in the same request.
> Yes, but in this case there should be multiple cookies returned by the 
> getHeaders() and getCookies()
> method. Currently there is only one in each.
>> Best regards,
>> Konstantin Kolinko
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message