https://issues.apache.org/bugzilla/show_bug.cgi?id=52697
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Mark Thomas <ma...@apache.org> 2012-02-17 17:32:08 UTC ---
(In reply to comment #0)
> In org.apache.catalina.connector.Response.recycle(), the outputStream.clear()
> method is only called if Globals.IS_SECURITY_ENABLED ||
> Connector.RECYCLE_FACADES. Why is that?
Speed. Reduced GC.
> Now that I looked into the source, I know how to ensure that
> outputStream.clear() is being called.
Excellent. I wish more folks took advantage of the ability to read the source
if they can't find what they need in the documentation.
> But can't it always be called?
No.
> But logically, I think it would make more sense recycling the outputBuffer
> the last thing.
No it doesn't.
> Also, I think it would make sense that CoyoteOutputStream.close() only calls
> ob.close() "if (ob != null)". That way closing an already cleared
> CoyoteOutputStream would not cause a NPE.
Again no. We want the NPE in that case since it would indicate a bug in the
connector code.
> These two changes: Response.recycle() should always call outputStream.clear()
> and CoyoteOutputStream.close() should only call ob.close() if ob != null would
> have made a world of difference to to us.
So would not have using a buggy third-party library. As would using
-Dorg.apache.catalina.connector.RECYCLE_FACADES=true
Tomcat, like most application servers, reuses objects to reduce GC and improve
performance. That re-use does bring risks of misbehaviour with buggy
applications and/or libraries. That is the price you pay for improved
performance. Folks that prefer to take the performance penalty have an option
that allows them to do so.
Further discussion of this topic belongs on the users list, not bugzilla.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
