Hi,
I had a look at the documentation and the tomcat source to get a better
understanding
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
org.apache.coyote.AsyncStateMachine.asyncPostProcess(AsyncStateMachine.java:202)
at
org.apache.coyote.AbstractProcessor.asyncPostProcess(AbstractProcessor.java:116)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1653)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown 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.
Regards,
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 <kule...@flexsecure.de>:
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:
http://markmail.org/thread/pxh6bk6saowy3rk6
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
