Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <3D6E10CB.90601@mail.more.net>
Date: Thu, 29 Aug 2002 07:17:15 -0500
From: Glenn Nielsen <glenn@mail.more.net>
Organization: MOREnet
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US;
 rv:1.0rc3) Gecko/20020607
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: Re: cvs commit:
 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core
 StandardContext.java
References: <20020826121559.73211.qmail@icarus.apache.org>
 <3D6C9F52.5020008@apache.org> <3D6CBD68.9060304@mail.more.net>
 <3D6CBEC2.8050900@apache.org> <3D6CC538.5080106@mail.more.net>
 <3D6CCBC5.4080909@apache.org> <3D6CD5E7.7060908@mail.more.net>
 <3D6DDC84.3000407@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Remy Maucherat wrote:
> Glenn Nielsen wrote:
> 
>> Remy Maucherat wrote:
>>
>>> Glenn Nielsen wrote:
>>>
>>>> Capturing of stdout/stderr has been enabled in Tomcat 4.1 for 2-3 
>>>> months now.
>>>
>>>
>>>
>>>
>>> I don't think it was, as RequestBase is deprecated, and is not used 
>>> anymore (except in the old connectors).
>>>
>>>> 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.
>>>
>>>
>>>
>>>
>>> Ok.
>>>
>>>> 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.
>>>
>>>
>>>
>>>
>>> I don't have many problems with capturing during servlet init. It 
>>> makes more sense to me to capture that data (no rational explanation, 
>>> just a feeling).
>>> It's not done during shutdown, BTW.
>>>
>>
>> I can add that. :-)
>>
>>
>>> I can also make that optional using the same flag.
>>>
>>>> The thread sync issue is a good point, but this can be improved by 
>>>> changing
>>>> the SystemLogHandler to use Thread Local variables.
>>>
>>>
>>>
>>>
>>> Thread local is quite slow, from what I saw with OptimizeIt, so I 
>>> don't want to use it.
>>>
>>
>>  From reading the section on Thread Local Performance here:
>>
>> http://www-106.ibm.com/developerworks/java/library/j-threads3.html#h15292
>>
>> Thread local performance differs based on the JVM.
>>
>> 1.2 -> poor
>> 1.3 -> better than normal sync _if_ you have alot of thread contention.
>>        In production where performance is an issue Tomcat can spawn alot
>>        of threads, so Thread Local could be of benefit.
>> 1.4 -> much faster than normal sync
>>
>> Based on this, for the long run, I think its better to switch to 
>> Thread Local.
> 
> 
> Thanks for the information :)
> 
>> In the long run it may be better to add support for CaptureLog to the 
>> base class
>> for a Processor so that the thread sync issues can be avoided altogether.
> 
> 
> So I'll add support for log capture on shutdown (I think it's as useful 
> to have it as on startup). My personal preference is to leave the 
> capture switched off by default for the critical path, as it would 
> confuse developers (IMO).
> 

Thanks

The number of people using Tomcat for development is probably much larger than
those using it in production.  So I am removing my previous -1 for the default
setting of swallowOutput.

Glenn


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