On Tue, Dec 8, 2009 at 5:08 AM, Olle Hallin <olle.hal...@hit.se> 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 (caused by �...@incudejavascriptlibrary("classpath:..."))
> and
> the other is in
> org.apache.tapestry5.ioc.internal.services.PerthreadManagerImpl
>
> The ZipFile bottleneck is harmless, since we will use a CDN in production.
> The second one is harder to work-around, since it is caused by
> RequestGlobals.storeServletRequestResponse().
>
> I have browsed PerthreadManagerImpl.java, and have found two cases where a
> lock on "this" is requested.
>
> In both cases the lock is requested before accessing a ThreadLocal
> (ThreadLocal.get() and ThreadLocal.remove()).
> Since ThreadLocal is thread-safe, external locking is uneeded.
>
Unfortunately, ThreadLocal.get()/remove() was buggy and not thread
safe in JDK 1.5.
> Shall I file a JIRA issue, or have I missed something?
>
> We use T5 5.1.0.5
>
> Olle Hallin
> Senior Java Developer and Architect
> olle.hal...@crisp.se
> www.crisp.se
> http://www.linkedin.com/in/ollehallin
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
