velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben <>
Subject Re: using Velocity in an untrusted environment
Date Fri, 07 Apr 2006 16:59:44 GMT
I just don't want to have to create a new thread every time a request comes 
in, since that would double the number of threads on the server from 1 per 
page access to 2. If i were to create a new thread it would be easy to 
interrupt it, by doing thread.join(number of milliseconds); and then 

Thanks about pointing out foreach.maxloops property, is there a list 
somewhere of all properties i can set for velocity? I browsed through the 
docs, but didn't find them.

----- Original Message ----- 
From: "Nathan Bubna" <>
To: "Velocity Users List" <>
Sent: Friday, April 07, 2006 12:18 PM
Subject: Re: using Velocity in an untrusted environment

i don't see why there should be any problem with using a separate
thread.  servlet requests are all about threads.

if it is just #foreach looping that you are concerned about, then
there is already a directive.foreach.maxloops property that you can

> If people are interested I can paste the results of my experiment when I 
> am
> done, as well as any modifications I make.
> Hmm.  To be honest, I'm not interested in having this be an
> out-of-the-box piece of Velocity.  Adding this "maximum cost" option
> for "every operation it does" would mean a performance hit, a big rise
> in complexity, or both.  I would want to see a lot of interest in this
> from others before i would let this change go through without vetoing
> it.  I really don't think this is something most of our users want or
> need.  No one else has asked for it (to my memory) in the five years
> i've been around.
> For you, however, it ought to be fairly easy straightforward to create
> a VelocityRunnable that you can start in a new Thread to do the
> template merge/render and then have the request thread check up on it
> (sleeping in between checks, of course) periodically.
> The tricky part is stopping the rendering thread when it goes over
> time.  It's not really safe to use the deprecated Thread.stop()
> method.  The recommended replacement
> (
> is to create velocityRunnable.stop() method that can flip a flag to
> interrupt the rendering.  But Velocity doesn't have any built in way
> to *interrupt* the rendering.  The only thing i'm aware of is the
> #stop directives ability to make Velocity stop sending output to the
> writer.  So far as i know, it doesn't actually stop the template
> processing (personally, i think it'd be better if it did).
> To actually stop template processing, you will probably have to alter
> some of the internals yourself.  The driver of the rendering process
> is a simple for() loop in the render(context, writer) method of the
> SimpleNode class.  all the nodes extend this class, so this method is
> how the AST is traversed.  I would imagine that the "real way" to do
> this would be to somehow put the flag in that for() loop's conditional
> that would be shared by all nodes in that template.  That probably
> means you need a flag that resides in the context that's being passed
> around.  When the flag is tripped, no further nodes should be
> rendered.
> Of course, i'm not 100% sure that that is all you'll need to change,
> and it also might not catch all possible problems.  For instance, if
> it is the rendering of a particular leaf on the AST that is taking
> forever, then this won't stop that node's rendering; it would only
> stop further traversal of the tree.  Still, that is hopefully enough
> info to get you started...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message