velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Bubna" <>
Subject Re: Velocity Performance and Concurrency issues
Date Fri, 25 Jul 2008 05:02:37 GMT
On Thu, Jul 24, 2008 at 2:53 PM, Raymond Auge <> wrote:
> 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(
>        - waiting to lock <0x00002aaad093d940> (a
> org.apache.velocity.util.introspection.IntrospectorCacheImpl)
>        at
> org.apache.velocity.util.introspection.Introspector.getMethod(

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:
For additional commands, e-mail:

View raw message