On Thu, Jul 24, 2008 at 2:53 PM, Raymond Auge <[EMAIL PROTECTED]> wrote: #snip() > Under heavy load we hit a max throughput and thread dumps during this > time are completely filled with BLOCKED threads as bellow: > > [snip] > "http-80-Processor47" daemon prio=10 tid=0x00002aabbdb90400 nid=0x5a59 > waiting for monitor entry [0x0000000044c72000..0x0000000044c74a80] > java.lang.Thread.State: BLOCKED (on object monitor) > at > org.apache.velocity.util.introspection.IntrospectorBase.getMethod(IntrospectorBase.java:103) > - waiting to lock <0x00002aaad093d940> (a > org.apache.velocity.util.introspection.IntrospectorCacheImpl) > at > org.apache.velocity.util.introspection.Introspector.getMethod(Introspector.java:101) #snip()
I do find it interesting that there is so much blocking going on at this particular point. I didn't appearing all that high on any of the profiler outputs yet. Perhaps that's just oversight on my part or perhaps that may be because of the heavy evaluate() use in this particular case, but still, if we can find a way to speed it up, that would be good nonetheless. I'll look into it a bit. It may turn out to be another spot that mostly needs to wait for the JDK 1.5 concurrency classes, but perhaps there is something that can be done. I do notice right off the bat that the synchronization of the get() and put() methods of IntrospectorCacheImpl seems unnecessary as they are being used within a block synchronized on their instance. With re-entrant synchronization that might not make a big difference, but it's something. I bet we could also be more fine-grained here and synchronize on something like the Class being introspected. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
