I've put some comments into the issue itself.
On Tue, Dec 8, 2009 at 1:48 PM, Massimo Lusetti wrote:
> On Tue, Dec 8, 2009 at 4:03 PM, Howard Lewis Ship wrote:
>
>> Unfortunately, ThreadLocal.get()/remove() was buggy and not thread
>> safe in JDK 1.5.
>
> Do you actually mean 'is' not 'was' ?
>
On Tue, Dec 8, 2009 at 4:03 PM, Howard Lewis Ship wrote:
> Unfortunately, ThreadLocal.get()/remove() was buggy and not thread
> safe in JDK 1.5.
Do you actually mean 'is' not 'was' ?
Couldn't this be (re)written without using syncronized blocks?
--
Massimo
http://meridio.blogspot.com
On Tue, Dec 8, 2009 at 5:08 AM, Olle Hallin wrote:
> Hi!
>
> We are load testing our new high volume site before soft launch, and we have
> noticed that we have two sources of severe lock contention.
> Of 300 threads, in average 165 are waiting for one of these two locks.
>
> One is in ZipFile (ca
JIRA https://issues.apache.org/jira/browse/TAP5-945 created
Olle Hallin
Senior Java Developer and Architect
olle.hal...@crisp.se
www.crisp.se
http://www.linkedin.com/in/ollehallin
2009/12/8 Thiago H. de Paula Figueiredo
> Em Tue, 08 Dec 2009 11:08:38 -0200, Olle Hallin
> escreveu:
>
> Hi!
>
Em Tue, 08 Dec 2009 11:08:38 -0200, Olle Hallin
escreveu:
Hi!
Hi!
Shall I file a JIRA issue, or have I missed something?
I'm no expert at concurrency, but please post it so the committers with
the required knowledge can take a look at it. ;)
--
Thiago H. de Paula Figueiredo
Independ
Hi!
We are load testing our new high volume site before soft launch, and we have
noticed that we have two sources of severe lock contention.
Of 300 threads, in average 165 are waiting for one of these two locks.
One is in ZipFile (caused by @IncudeJavaScriptLibrary("classpath:...")) and
the othe
