I just realized that logic seemed flawed and should be something more
like:
if (_innerVelocityContext == null) {
_innerVelocityContext = new VelocityContext();
VelocityVariables.insertHelperUtilities(
_innerVelocityContext, null);
}
VelocityContext velocityContext = new
VelocityContext(_innerVelocityContext);
Where VelocityVariables.insertHelperUtilities(_innerVelocityContext,
null); adding a bunch of utils to the context.
On Thu, 2008-07-24 at 21:06 -0400, Raymond Auge wrote:
> Ok, before moving on those ideas, we've made a small change to the
> following:
>
>
>
> VelocityContext velocityContext = null;
>
> // LEP-6865
>
> if (_innerVelocityContext == null) {
> velocityContext = new VelocityContext();
>
> _innerVelocityContext = velocityContext;
> }
> else {
> velocityContext = new
> VelocityContext(_innerVelocityContext);
> }
>
> velocityContext.put("processor", processor);
>
> // Velocity variables
>
> VelocityVariables.insertVariables(velocityContext, request);
>
>
>
> Where "_innerVelocityContext" is a static instance.
>
> Does this seem like a logical move?
>
>
>
> My next questions is... IF the many "puts" made by
>
> VelocityVariables.insertVariables
>
> are actually utility classes and not runtime values, should these be
> added to the "_innerVelocityContext" so that their introspection
> meta-data is cached for subsequent use?
>
> OR does this increase the likelihood of encountering concurrency
> issues?
>
>
> Thanks,
>
> Ray
>
> On Thu, 2008-07-24 at 20:30 -0400, Raymond Auge wrote:
>
> > Thanks Will, Malcolm, All,
> >
> > I'll take in these ideas and see how we can work them into a
> > solution.
> >
> > Ray
> >
> > On Thu, 2008-07-24 at 16:39 -0700, Will Glass-Husain wrote:
> >
> > > One big problem is that you are using Velocity.evaluate() which is not
> > > recommended for high-volume use.
> > >
> > > If you store your templates as text files and use a ResourceLoader to
> > > retrieve as a Template object, Velocity has very efficient caching.
> > > You can store your templates as files (use FileResourceLoader), in the
> > > classpath (ClasspathResourceLoader), or in a database
> > > (DatasourceResourceLoader).
> > >
> > > The (unreleased) Velocity 1.6 (in source control trunk) contains
> > > further improvements. But you should see order of magnitude
> > > improvements from retrieving your templates with a ResourceLoader (and
> > > the caching option on) vs. Velocity.evaluate().
> > >
> > > See the developer's manual for more details.
> > >
> > > WILL
> > >
> > >
> > > On Thu, Jul 24, 2008 at 3:46 PM, Malcolm Edgar <[EMAIL PROTECTED]> wrote:
> > > > 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]
> > > >
> > > >
> > >
> > >
> > >
> >
> > ----------------------------------
> > 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
>
> ----------------------------------
> 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
----------------------------------
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
