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=44310>. 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=44310 ------- Additional Comments From [EMAIL PROTECTED] 2008-01-29 04:24 ------- I agree the current servlet spec is quite clear about not reusing objects outside of the request/response scope. The servlet spec does not offer any support for asynchronous I/Os, which is the context of the current request. In order to improve overall robustness of tomcat in front of what can be considered bad programming in the context of the current servlet spec but is required to implement asynchronous SENDs (using an application-defined thread SEND pool that have no real way to sync with RECV errors without blocking), I suggested that the lifecycle of public objects (Response, OutputStream) referencing internal implementation details (OutputBuffer) be in sync. The outputBuffer is recycled, but public objects that may have been stored for application-defined purposes are still pointing to it, which is , in my opinion, not the best design possible. I have a design pattern of trying to keep related API objects' lifecycles in sync to avoid the kind of issue I was experiencing before applying the patch. I will anyhow ship my product with this patch in my installer , which packages tomcat inside. e.g.: the application I am talking about is a commercial Mobile SSL VPN based on tomcat. It may be bold, but it works like a charm... -- 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]
