I would recommend also applying the patch in this issue: https://issues.apache.org/jira/browse/VELOCITY-607. We have observed a huge improvement in performance.
On Wed, Aug 6, 2008 at 6:46 PM, csanders <[EMAIL PROTECTED]> wrote: > Huh small world, I'm recently profiling our web application and seeing the > same behavior using mergeTemplate and the file resource loader. Tons and > tons of blocked threads. > > I'll try the trunk and report the difference as well. > > > > > Nathan Bubna wrote: > >> 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] >> >> >> > > > -- > > Thanks, > Charlie > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
