Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 44310]  - Possible data packet corruption when
 sending data on the outputStream of a recycled response
In-Reply-To: <bug-44310-78@http.issues.apache.org/bugzilla/>
Message-Id: <20080129122424.13F52714208@brutus.apache.org>
Date: Tue, 29 Jan 2008 04:24:23 -0800 (PST)

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 cpierret@sparus-software.com  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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org