A small update on the matter: I've managed to track it down, but the details are rather application specific, so I don't want to bore you, but the scenario looks as follows:
- something posts a rather normal looking request to an url that is yet supported but obsolete (should be actually served by another pool of tomcats). - this request probably comes without cookies - the webapp tries to set a "vi" - visitor id - cookie till infinity, the requests lasts and lasts and lasts (longest detected was 25h). - at one point the amount of cookies in the response is larger than the free memory, so old gen is running full, tomcat freezes, asta la vista... Now, the problem is, that there is no evidence in the thread dumps of infinite loops or anything. Maybe because most thread dumps are taken at the moment when the tomcat is frozen and aren't reliable anymore. However it it were recursion, it would be aborted faster (stackoverflow) or visible in the thread dump, but it's not. The other explanation would be a direct infinite loop in the application, but that should also be visible in the thread dump and its not. The last thing I can imagine is that the request somehow gets redirected or forwarded infinitely during processing, but is not leaving tomcat entirely and just reenters the processing, keeping the outer request object, where the mimeheader fields are stored. Is something like this possible? The (probably most outer request) in manager which was found in all cases is always shown as S(ervice), 0Kb size, and being processed very very long time... Any ideas, how an infinite redirection/forward loop can be created without leaving tomcat? regards Leon --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
