Thanks for pointing the way, I'll definitely take a look at the SimpleNode
class and see if it can be used for my purpose. I don't want to use a
separate thread since by me the render function is called from within a
servlet running inside resin, so what i'll probably do is have it check the
time, let's say every 10,000/100,000/1,000,000 loops or so, depending on
how many loops it does per second, and if it's past the time limit stop the
render process, or maybe just limit the rendering process to a certain
amount of loops, to prevent people from writing templates with a near
infinite loop. I do some work with Yahoo's RTML scripting language, which is
being interpreted by a perl script running on Yahoo's servers, and I think
that's what Yahoo does, limit the loops to 10,000,000 iterations or so.
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
(http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html)
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
