-----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. > 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 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? > 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. > 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? > 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
