-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
On 8/31/2010 4:49 PM, Bill Davidson wrote:
> On 8/31/2010 12:16 PM, Christopher Schultz wrote:
>> Or, just remove the ThreadLocal manually. Since you know it's name, it
>> should be easy to remove. There are two obvious ways to remove these
>> T
On 8/31/2010 12:16 PM, Christopher Schultz wrote:
Or, just remove the ThreadLocal manually. Since you know it's name, it
should be easy to remove. There are two obvious ways to remove these
ThreadLocals in a webapp:
1. Modify all the code that uses the iCal4j library so that, after
performing it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ognjen,
On 8/31/2010 4:51 AM, Ognjen Blagojevic wrote:
Is there no way for me to kill these?
>>>
>>> Not easily. Most uses of ThreadLocal seem to be blissfully
>>> (sometimes arrogantly) unaware of thread-pooling mechanisms and app
>>> servers.
On 8/31/2010 1:21 PM, Caldarale, Charles R wrote:
It seems to me that using static ThreadLocal's isn't going to
save that much overhead vs. just creating a regular local object
each time you run.
The above is even more true in modern JVMs with method inlining and escape
analysis - such an obje
> From: Bill Davidson [mailto:bill...@gmail.com]
> Subject: Re: iCal4j and ThreadLocal
> It seems to me that using static ThreadLocal's isn't going to
> save that much overhead vs. just creating a regular local object
> each time you run.
The above is even more true i
On 8/30/2010 9:18 PM, Caldarale, Charles R wrote:
There's a lot of baggage implemented to support ThreadLocal. It's one of those
deceptively easy-to-use Java concepts that utilizes a lot of plumbing
underneath the covers (e.g., a specialized per-thread expandable hash map, weak
references).
On 31/08/2010 11:30, Jess Holle wrote:
> On 8/31/2010 4:03 AM, Leon Rosenberg wrote:
>> On Tue, Aug 31, 2010 at 10:51 AM, Ognjen Blagojevic
>> wrote:
>> Is there no way for me to kill these?
> Not easily. Most uses of ThreadLocal seem to be blissfully (sometimes
> arrogantly) unawar
On 31/08/2010 04:38, Caldarale, Charles R wrote:
>> From: Jess Holle [mailto:je...@ptc.com]
>> Subject: Re: iCal4j and ThreadLocal
>
>> Rather replacing all the threads ASAP upon any reload
>> seems like a much more forgiving implementation.
>
> There was an
On 8/31/2010 4:03 AM, Leon Rosenberg wrote:
On Tue, Aug 31, 2010 at 10:51 AM, Ognjen Blagojevic
wrote:
Is there no way for me to kill these?
Not easily. Most uses of ThreadLocal seem to be blissfully (sometimes
arrogantly) unaware of thread-pooling mechanisms and app servers. Ideally,
thes
On Tue, Aug 31, 2010 at 10:51 AM, Ognjen Blagojevic
wrote:
Is there no way for me to kill these?
>>>
>>> Not easily. Most uses of ThreadLocal seem to be blissfully (sometimes
>>> arrogantly) unaware of thread-pooling mechanisms and app servers. Ideally,
>>> these ThreadLocal instances would
Is there no way for me to kill these?
Not easily. Most uses of ThreadLocal seem to be blissfully (sometimes
arrogantly) unaware of thread-pooling mechanisms and app servers. Ideally,
these ThreadLocal instances would instead be created in a pool for the webapp
to use, rather than being tied
> From: Bill Davidson [mailto:bill...@gmail.com]
> Subject: Re: iCal4j and ThreadLocal
> It still felt a bit fuzzy to me. It's getting a little more
> in focus but it's kind of a weird thing.
There's a lot of baggage implemented to support ThreadLocal. It's o
> From: Jess Holle [mailto:je...@ptc.com]
> Subject: Re: iCal4j and ThreadLocal
> Rather replacing all the threads ASAP upon any reload
> seems like a much more forgiving implementation.
There was an effort underway to do just that a few months ago for Tomcat 7; not
sure if it ev
On 8/30/2010 5:25 PM, Mark Thomas wrote:
'Fraid not.
The right solution here is for the iCal4j library to fix the leak or
provide a mechanism to enable clients to trigger clean-up on shutdown
(which can then be called from a Servlet context listener). Generally,
library authors have moved quick
Overall I think this is a rock-and-a-hard-place issue.
ThreadLocals work wonderfully behind opaque library walls in most cases.
The exception is when there are threads used with your library whose
lifecycle is beyond that of the classloader which loads your library --
as in Tomcat web apps, f
On 8/30/2010 2:08 PM, Caldarale, Charles R wrote:
I'm not really clear on how ThreadLocal works.
http://download.oracle.com/javase/6/docs/api/java/lang/ThreadLocal.html
And, as usual, GIYF.
I actually had already read that, and a few other things I found in Google.
It still felt a b
On 30/08/2010 22:08, Caldarale, Charles R wrote:
>> From: Bill Davidson [mailto:bill...@gmail.com]
>> The iCal4j author assures me that this isn't really a memory leak.
>
> I suppose it depends on your definition of memory leak, but I'd certainly
> consider it one. It adds to the heap, and does
> From: Bill Davidson [mailto:bill...@gmail.com]
> Subject: iCal4j and ThreadLocal
> The iCal4j author assures me that this isn't really a memory leak.
I suppose it depends on your definition of memory leak, but I'd certainly
consider it one. It adds to the heap, and doesn't go away automatica
18 matches
Mail list logo
