Hi Auge, On the Velocity development list there is some ongoing work to address this issue. I would recommend that you try the performance patches and get in contact with these people.
https://issues.apache.org/jira/browse/VELOCITY-606 regards Malcolm Edgar On Fri, Jul 25, 2008 at 7:53 AM, Raymond Auge <[EMAIL PROTECTED]> wrote: > Hello All, > > My name is ray Augé. I am an engineer working for Liferay, Inc. on the > Liferay Portlet project. > > We have a critical issue with Velocity performance where under large > load Velocity becomes a bottleneck for scalability. > > Now, I'm fairly certain that this is perhaps because we are using > Velocity in a way which may not leverage its scalability features. > > Allow me to explain the problem and our usage. > > 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) > at > org.apache.velocity.util.introspection.UberspectImpl.getMethod(UberspectImpl.java:165) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:184) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203) > at > org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294) > at > org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) > at org.apache.velocity.app.Velocity.evaluate(Velocity.java:322) > at org.apache.velocity.app.Velocity.evaluate(Velocity.java:195) > at > com.liferay.portlet.layoutconfiguration.util.RuntimePortletUtil.processTemplate(RuntimePortletUtil.java:238) > at > com.liferay.portlet.layoutconfiguration.util.RuntimePortletUtil.processTemplate(RuntimePortletUtil.java:194) > at > org.apache.jsp.html.portal.layout.view.portlet_jsp._jspService(portlet_jsp.java:801) > [/snip] > > Now here is what the Velocity usage looks like for that particular > thread: > > TemplateProcessor processor = new TemplateProcessor( > servletContext, request, response, portletId); > > VelocityContext vc = new VelocityContext(); > > vc.put("processor", processor); > > // Wrap a bunch of puts... > > VelocityVariables.insertVariables(vc, request); > > // many more puts here... > vc.put(...); > vc.put(..); > > StringWriter sw = new StringWriter(); > > try { > Velocity.evaluate( > vc, sw, RuntimePortletUtil.class.getName(), > content); > } > catch (Exception e) { > _log.error(e, e); > > throw e; > } > > // eventually do > return sw.toString(); > > etc.. > > Is there an obvious miss-use of Velocity than anyone can identify here? > > Wondering if we are supposed to re-use a common inner context? IF so, > would it be a singleton? a pool of re-usable contexts? something else? > > Many thanks for any input, > > > ---------------------------------- > Raymond Augé > Software Engineer > Liferay, Inc. > Enterprise. Open Source. For Life. > ---------------------------------- > > Liferay Meetup 2008 – Los Angeles > > August 1, 2008 > > Meet and brainstorm with the creators of Liferay Portal, our partners > and other members of our community! > > The day will consist of a series of technical sessions presented by our > integration and services partners. There is time set aside for Q&A and > corporate brainstorming to give the community a chance to give feedback > and make suggestions! > > View Event Details > > Register Now > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
