Hello Christopher,
thanks for your answer.
Am 15.07.2014 16:12, schrieb Christopher Schultz:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Simon,
On 7/9/14, 4:51 AM, Simon Kulessa wrote:
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.
Requests, yes. I haven't looked to see if Cookies would be re-usable
but it seems plausible.
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?
The client's IP is irrelevant: Tomcat uses a pool of objects and
re-fills each object with data from an incoming request. These
objects, as far as the web application should be concerned, should
have a valid lifetime equal to the request itself. The servlet spec
requires these semantics, so this isn't some weird Tomcat thing.
Tomcat has chosen to pool these objects for a small performance gain
when it comes to memory management and garbage collection.
If your application retains references to these objects after they
become invalid, they may contain invalid data or valid data from
another request after they should have become invalid form the
perspective of the original request.
If you need data from a request, cookie, etc. then you should copy it
somewhere safe before the request ends.
We do not cache any request specific information.
The IP relation itself is irrelevant - it seems that the reused object's
contains more 'old' informations
than I previously assumed. The header itself and the requestedSessionId
seems to be changed,
the sourceIP and the cookie stay the same.
In our code we hold a reference to the httpSession outside of the
request (in a application scoped map).
HttpSession objects should be cacheable in this way. You do have to be
careful that when the HttpSession expires, you remove those object
references from your application-scoped Map or you risk memory exhaustion.
We remove them we one of the methods (onError, onTimeout, onComplete)
of the javax.servlet.AsyncListener is called. So this should not be an
issue.
We use this session object to read the SessionId, to invalidate or
to adjust the session timeout from outside a client request.
That should be okay. Are you storing request or response objects in a
similar way?
No, we do not store any request or response objects.
What I noticed is that if you invalidate the session from outside, while
a request (in another Thread)
is still alive for this session, request.getSession().getId() may return
a different sessionId than before.
Is that supposed to be the case or is this a bug in Tomcat?
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.
Good so far.
Later another command of the client with the old cookie arrives and
is rejected by our server.
Seems reasonable.
After this any other request coming from the same IP fails.
Fails how? Exception? Unexpected behavior? Please be specific.
We added some logic to check the content of the cookies. But the cookies
does
not contain a valid data (for our application) at this point this it is
not the
cookie that was part of the header.
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'.
How many cookies do you see? The client can provide more than one
JSESSIONID cookie. Also, when the request arrives with the "old"
JSESSIONID cookie, it does not mean that the old session id is valid.
It's just that the client still thinks the session is valid.
Are you using Tomcat-managed sessions, or are you doing your own
session management?
I see only one cookie in the header.
I know that the cookie does not need to be valid, but this is not the
issue here.
At this point I assume that the client does not even send the 'old' cookie.
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.
I believe there are some edge cases related to acync processing that
have been identified and fixed in the versions between yours (7.0.29)
and the current release version (7.0.54). You should really upgrade
regardless of whether or not this fixes your particular problem(s):
there have been many security fixes classified as "important" since
your version (which is nearly 2 years old).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTxTbEAAoJEBzwKT+lPKRYwAkP/0b2PRsnC0ppCWOBg7Y2r7pO
TIH/w8J+BXCfJqkr9mnj9dHpTdb9XM824NTWaQaIc4fbyUtreDoTp9zPBi0+/n/v
RPTNuEmbPpvCa/imhs0VfOBTTslC9Il22tF9CxqvtzqtSEFyiS1Npdvyxl8zy/rJ
heksVx3nKX6oaZTsdJ8taWpRAcm2ZCwmacEzHYFpgLZ2ml56Kgds+Q5K+PpPS9jH
ydg5jNoDCzUqs7cMcW5uRCdnUbEFLS2P0ON6c8l263glhI/D68ljd6eL7He8J8RQ
lp5vZ70jktp9gS8K2Nz0qSpHkI7HhgvKUFO/gG33lvcAAWtmZPkOS5xEe7lCNLzQ
RuBwMMmgY7nvtXkeSeJVX/YH1kQkIUwiIv84K9O4c9jjIZHTR4VU4jCRiSQAQaR8
tlQgZ9dNJAlfXE5FtYYZsCJ3lMg6meWNJkqP3XZtqVPfX3A2K1o+phAvcSCLEFpz
Hy/dcnhTYQyfvovex982zPavj7Q9Ou+KXLw6UZRGhCmqxMA8VATyHNlUmD2zomnl
6IveC51hmt36HAwYk9QWZPGeLt8BucCnTkfkSpPU0igzfHXMiSjoZLdTw5RemVDx
aLo5a+4ii/t6rJeYfuIGtYRZFNYnu8/tuOEdGjNygY4qKKDwHP9dkBhDaRs4AU6K
ClFG16OUDuEqTGkGiA9f
=Auy4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
