velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Auge <ra...@liferay.com>
Subject Velocity Performance and Concurrency issues
Date Thu, 24 Jul 2008 21:53:18 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message