-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Simon,
On 7/16/14, 4:02 AM, Simon Kulessa wrote: > Am 15.07.2014 16:12, schrieb Christopher Schultz: 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. I checked, and Tomcat does not appear to cache Cookie objects in any way. If the request object is cached and there is a terrible bug, it might be possible to re-read an incorrect session cookie from an old set of request headers. I honestly think it's unlikely that there is such a bug in Tomcat. At this point, I think you're probably going to have to create a proof-of-concept web application that reproduces this problem. Do you think you could boil-down the problem to a single servlet that demonstrates what you are observing? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTxnPhAAoJEBzwKT+lPKRYWF4P/iP9NXxYvIVLi9rKSUEmjDGI hcSJ1uMGQDOty0ycNaijR5N9w1QTqhLsoV1cgLaTK3vSvlNpI79b9TEj16EhfY4B oLAq2QyYLKbwiJm28gp7zcWNup6UgSAdCi/e84g+m0yiD7xZCwgfARAe6k3Idm3q xjyh6FkNlq9lGxXbRv5TVk5+Nn6/qRQsv6p98DTGna1ypFwupEWB6COzafRKAjuk icSn1XIAfKSb5NtznPSxqzrxG389I+PX7cFcrxlXHOATY8j6M9kL6JGrKWJS/8bT KGmP9u6dp7Wuq3/NNYKUhSvDSCILhPqx4ONWl8oTLW0u/crVroKfdJyLFoO89plF hN3SWCXS7K8MhRHYTZM4qwicjfyUWVlF/+HthO5zvEakfJSDA6KeeCh/Vhtwmi0u 8M9SUM3d05Zv5uZoDAOf27ULDg186kIZD5fnmW2hrV/3ToYseb5yCLY1q71LQfKT RWNyObvLS/bjouhf6xzozluLD8VZtCNtzptdvx+iYJGzoyUp8Q4/nAtS11FLMn8H JFzaCFXN7+GEuKj5r/5iE5X4qZPNMIvetW8d2Bp91lZb3y2UPH/9a2CL4GzHyRSp Xdv94nkDGZlp21sb7xfBgVdbHVxwHz5zITeAbT4sPkq23Wf5O+wtDF+uavmdkorG 7bOwKIvWGaLllyaXbyLB =8LTx -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
