-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
ill...@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 automatically when
the applic
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,
Sigh. Using Tomcat 6.0.26 and trying to use iCal4j to generate calendar
files so that date/time events in my app can be exported to the user's
calendar.
iCal4j uses static ThreadLocal's to protect SimpleDateFormat and some
other things. When I shut down Tomcat I get these disturbing messages:
19 matches
Mail list logo
