Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <461D833F.4080702@hanik.com>
Date: Wed, 11 Apr 2007 18:54:23 -0600
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: memory leak with shrinking thread pools
References: <461D0108.7070104@hanik.com> <461D0F07.1000004@hanik.com>
 <461D4D4D.6090108@apache.org> <461D6563.2030701@hanik.com>
 <461D75BA.1070606@apache.org>
In-Reply-To: <461D75BA.1070606@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> you're of course right, I think I simply need to get rid of the 
>> thread local cache, and use the processor cache instead.
>> do you have any idea of the performance penalty? I'd probably use a 
>> ConcurrentLinkedQueue or something instead of 
>> synchronized{processorCache}
>
> There's a penalty already for using an executor (unfortunately). So 
> there could be a check: if using an executor, then use a processor 
> pool of some sort (a dumb synced stack could do it, but I don't know 
> if it would be better or worse speed wise - maybe about the same since 
> there's no read at all, only modifications of the "collection"), 
> otherwise use the thread local. Maybe there could be a better 
> solution, but it's probably the easy one.
>
> I didn't think about this leak issue when I thought about supporting 
> executors.
me neither, but then again, the thread local is not the real problem. 
its the requestinfo and requestgroupinfo objects, has the funky circular 
dependency, and ties it back all the way to the "handler". Had it not 
been for those, then there would have been no leak, since the objects 
would have been collected when the thread died, and the thread local 
reference disappeared.

Filip
>
> R�my
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


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