-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
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
On Tue, Aug 31, 2010 at 10:51 AM, Ognjen Blagojevic
ognjen.d.blagoje...@gmail.com 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
On 8/31/2010 4:03 AM, Leon Rosenberg wrote:
On Tue, Aug 31, 2010 at 10:51 AM, Ognjen Blagojevic
ognjen.d.blagoje...@gmail.com 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
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 effort underway to do just that a few months
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
ognjen.d.blagoje...@gmail.com wrote:
Is there no way for me to kill these?
Not easily. Most uses of ThreadLocal seem to be blissfully (sometimes
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).
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 in modern JVMs with method
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
-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. Ideally, these
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
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:
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
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 doesn't go
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
: 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 application is undeployed (and likely prevents
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
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 ever got fully
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 one of those
deceptively easy-to-use
19 matches
Mail list logo
