tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@mail.more.net>
Subject Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java
Date Wed, 28 Aug 2002 12:42:32 GMT
Remy Maucherat wrote:
> Glenn Nielsen wrote:
> 
>> Remy Maucherat wrote:
>>
>>> glenn@apache.org wrote:
>>>
>>>> glenn       2002/08/26 05:15:59
>>>>
>>>>   Modified:    catalina/src/share/org/apache/catalina/connector
>>>>                         RequestBase.java
>>>>                catalina/src/share/org/apache/catalina/core
>>>>                         StandardContext.java
>>>>   Log:
>>>>   Fix for BUG 11947.  Change where startCapture/stopCapture is 
>>>> invoked to
>>>>   prevent memory leaks from the SystemLogHandler.
>>>
>>>
>>>
>>>
>>> I'd like log swallowing to be optional and disabled by default. It 
>>> will confuse users too much otherwise (they're used to using Sys.out 
>>> to debug).
>>> It is also not a good idea to pay the performance cost when the 
>>> feature is not needed IMO.
>>>
>>> I plan to add a "swallowOutput" flag to StandardContext, with its 
>>> default to false.
>>>
>>> Remy
>>>
>>
>> I do think the feature is needed, especially for production systems.
>>
>> Many API's used by a web application don't know they are being used in 
>> a web
>> application and have no access to the servlet context log, they use 
>> stderr
>> and stdout.  It is very confusing during production if errors 
>> generated by
>> these API's are put in catalina.out and other errors are in the 
>> Context log.
>> Putting all the stdout/stderr output for a web app into one log makes 
>> it easier
>> to debug a problem.  Also, when the output goes to catalina.out there 
>> are no
>> timestamps which makes it difficult to correlate output in 
>> catalina.out with
>> the context log.
>>
>> For me, debugging is easier if everything related to a webapp is in 
>> the same log,
>> and with timestamps.
>>
>> This is just a change in behaviour, I don't see a problem with having 
>> it enabled
>> by default as long as it is documented.
>>
>> -0 for adding the flag
>> -1 for setting default behaviour to disable putting stderr/stdout in 
>> the context log.
> 
> 
> Most Tomcat users are developers, and do not care about your 
> "production" ready feature. IMO system administrators will have to tweak 
> their Tomcat installation, no matter what we do. OTOH, casual developers 
> are going to be deeply confused and annoyed by the feature.
> 
> I'm not happy with the patch you committed yesterday, and which forced 
> redirection (at the cost of adding two synced hashtable operations in 
> the critical path).
> 
> So -1 for the patch you committed yesterday.
> 
> (I think the code I just committed is an acceptable compromise, so I'd 
> appreciate it if you retracted your veto; if you don't, we'll have to 
> revert the last 2 StandardContext commits)
> 
> Remy
> 
> 

Capturing of stdout/stderr has been enabled in Tomcat 4.1 for 2-3 months now.
What I committed was a bug fix.  If you revert it, capturing stderr/stdout code
will still exist, you would just put back in place a memory leak.

There is another place where you will need to implement your SwallowOutput flag,
in StandardWrapper.java.  It captures output from a load on startup servlet.

The thread sync issue is a good point, but this can be improved by changing
the SystemLogHandler to use Thread Local variables.

Why don't we wait and see what other tomcat developers think of this.

Releasing 4.1.10 can wait 24-36 hours.





--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message