DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37356>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37356 ------- Additional Comments From [EMAIL PROTECTED] 2006-06-09 15:31 ------- Remy: I see two possible options. 1) Remove the code to keep sessions alive if in the middle of downloading and past their timeout. While this is not standard--this very well may be needed in many customer environments, and changing this behavior could break applications that rely on this functionality. 2) Properly synchronize the broken code. I realize that you object to the performance overhead of a couple synchronize blocks. I'd like to reference the following pages: http://www-128.ibm.com/developerworks/java/library/j-jtp04223.html http://www-128.ibm.com/developerworks/java/library/j-threads1.html Both of these pages state that synchronization overhead is much less than most developers believe, and that modern JVM's are highly optimized to provide fast synchronization. Furthermore, synchronization is a fixed overhead and barely noticable unless tested with empty or mostly empty methods which are called repeatedly. Tomcat's request handling does not resemble anything close to an empty method, and most likely the overhead of synchronization would be negligable. The only way to know the overhead of adding two synchronized blocks for sure would be to add the relevant code and do performance testing. Perhaps if you agreed to consider a proposed patch to properly synchronize based on performance results, someone would be willing to give you the relevant fix. As things currently are, session expiration in Tomcat is broken on multi-processor systems. This is a SEVERE bug and worth a small amount of performance loss to fix. Furthermore, the synchronization should be performed on the session rather than globally. The vast majority of all requests would never contend for the synchronization lock in this case--further reducing the overhead even more. Only multiple requests on the same session would be serialized, and this would most likely not limit scalability of Tomcat. I personally would rather see the appropriate synchronization added and performance testing done to validate that the overhead is minimal. I believe that this solution would be better than possibly creating a regression in behavior for people who use Tomcat to perform long operations with a "short" timeout (for instance: hosting very large files to users on slow connections). Either way, the problem that needs to be fixed is session management. Having a broken session management system which does not properly invalidate connections is unacceptable. The workaround for terming very long term sessions also seems like a very bad idea to me. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
