You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by "Kitching, Simon" <Si...@airnz.co.nz> on 2010/09/01 07:02:04 UTC
Velocity class thread-safety problems
Hi All,
I've got some code using Velocity which failed under load. Can you
confirm that the Velocity class is meant to be thread-safe? If so, I'll
file a bugreport.
Scenario:
* Velocity version 1.6.1, java 1.6, linux
(also fails with velocity-1.6.4)
* Using a complex template with macros
* Using a separate context object per thread
* Invoking Velocity.evaluate(context, out, "", templateText)
Results:
* Under heavy load from single thread, all ok
* Under light load from multiple threads, all ok
* Under heavy load from multiple threads, macro references like
"#macroname" intermittently don't get invoked during template
processing; the "#macroname" text appears literally in the output
instead.
Simply replacing calls to
Velocity.evaluate(...)
with
VelocityEngine ve = new VelocityEngine();
ve.init(props);
ve.evaluate(...)
fixes the issue.
I've confirmed the problem with a unit test; I can simplify it and
submit it if this really is considered a bug.
>From the documentation, email lists, etc. I believe that using the
Velocity singleton *should* have worked here (we don't need multiple
velocity configurations).
Comments?
Regards,
Simon
Good planets are hard to find - please think of the environment before you print this email.
____________________________________________________________________
CAUTION - This message may contain privileged and confidential
information intended only for the use of the addressee named above.
If you are not the intended recipient of this message you are hereby
notified that any use, dissemination, distribution or reproduction
of this message is prohibited. If you have received this message in
error please notify Air New Zealand immediately. Any views expressed
in this message are those of the individual sender and may not
necessarily reflect the views of Air New Zealand.
_____________________________________________________________________
For more information on the Air New Zealand Group, visit us online
at http://www.airnewzealand.com
_____________________________________________________________________
Re: Velocity class thread-safety problems
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/1 Kitching, Simon <Si...@airnz.co.nz>:
> I've confirmed the problem with a unit test; I can simplify it and
> submit it if this really is considered a bug.
Yes please.
> >From the documentation, email lists, etc. I believe that using the
> Velocity singleton *should* have worked here (we don't need multiple
> velocity configurations).
I believe that VelocityEngine instances should be thread safe. For
example, a single VelocityEngine is used in VelocityView class of
Velocity Tools. This class is accessed in a servlet environment as a
single instance, so VelocityEngine *should be* thread safe.
Do your tests fail even with a single VelocityEngine instance?
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Velocity class thread-safety problems
Posted by Nathan Bubna <nb...@gmail.com>.
On Fri, Sep 10, 2010 at 11:27 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> Nathan,
>
> On 9/7/2010 11:23 AM, Nathan Bubna wrote:
>> inline, local macros. only those macros have threadsafety issues.
>> and even then, only when they are being repeatedly parsed under load
>> (i.e. template caching off or repeated use of evaluate with the same
>> log tag). so i mostly recommend that you not run inline macros
>> through evaluate and turn template caching on when your app is under
>> load. of course, i would also hope that you would be doing the latter
>> anyway for performance.
>
> To sum up, then: this thread-safety problem is a parsing problem, not an
> evaluation problem?
exactly.
> Good. Of course, we always have caching enabled in production, so we're
> good :)
as it should be! :)
> -chris
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Velocity class thread-safety problems
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Nathan,
On 9/7/2010 11:23 AM, Nathan Bubna wrote:
> inline, local macros. only those macros have threadsafety issues.
> and even then, only when they are being repeatedly parsed under load
> (i.e. template caching off or repeated use of evaluate with the same
> log tag). so i mostly recommend that you not run inline macros
> through evaluate and turn template caching on when your app is under
> load. of course, i would also hope that you would be doing the latter
> anyway for performance.
To sum up, then: this thread-safety problem is a parsing problem, not an
evaluation problem?
Good. Of course, we always have caching enabled in production, so we're
good :)
-chris
Re: Velocity class thread-safety problems
Posted by Nathan Bubna <nb...@gmail.com>.
On Tue, Sep 7, 2010 at 7:32 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> Antonio,
>
> On 9/2/2010 10:02 PM, Kitching, Simon wrote:
>> On Wed, 2010-09-01 at 07:14 -0700, Nathan Bubna wrote:
>>> On Tue, Aug 31, 2010 at 10:02 PM, Kitching, Simon
>>> <Si...@airnz.co.nz> wrote:
>>>> Hi All,
>>>>
>>>> I've got some code using Velocity which failed under load. Can you
>>>> confirm that the Velocity class is meant to be thread-safe? If so, I'll
>>>> file a bugreport.
>>>
>>> generally, yes, but velocimacro settings can break that. what are
>>> your velocity properties?
>>
>> Just setting one property:
>> Properties p = new Properties();
>> p.put("velocimacro.permissions.allow.inline.local.scope", "true");
>> Velocity.init(p);
>>
>> And interestingly, this *is* what is triggering the problem.
>
> I'm using a subclass of the VelocityLayoutServlet (tools-1.4) for my
> purposes... will that be threadsafe when allow.inline.local.scope is set
> to true? Which class/object ends up being non-threadsafe?
inline, local macros. only those macros have threadsafety issues.
and even then, only when they are being repeatedly parsed under load
(i.e. template caching off or repeated use of evaluate with the same
log tag). so i mostly recommend that you not run inline macros
through evaluate and turn template caching on when your app is under
load. of course, i would also hope that you would be doing the latter
anyway for performance.
> Thanks,
> -chris
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Velocity class thread-safety problems
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Antonio,
On 9/2/2010 10:02 PM, Kitching, Simon wrote:
> On Wed, 2010-09-01 at 07:14 -0700, Nathan Bubna wrote:
>> On Tue, Aug 31, 2010 at 10:02 PM, Kitching, Simon
>> <Si...@airnz.co.nz> wrote:
>>> Hi All,
>>>
>>> I've got some code using Velocity which failed under load. Can you
>>> confirm that the Velocity class is meant to be thread-safe? If so, I'll
>>> file a bugreport.
>>
>> generally, yes, but velocimacro settings can break that. what are
>> your velocity properties?
>
> Just setting one property:
> Properties p = new Properties();
> p.put("velocimacro.permissions.allow.inline.local.scope", "true");
> Velocity.init(p);
>
> And interestingly, this *is* what is triggering the problem.
I'm using a subclass of the VelocityLayoutServlet (tools-1.4) for my
purposes... will that be threadsafe when allow.inline.local.scope is set
to true? Which class/object ends up being non-threadsafe?
Thanks,
-chris
Re: Re: Velocity class thread-safety problems
Posted by "Kitching, Simon" <Si...@airnz.co.nz>.
Thanks Antonio, Nathan,
I've created JIRA issue:
https://issues.apache.org/jira/browse/VELOCITY-776
On Wed, 2010-09-01 at 07:14 -0700, Nathan Bubna wrote:
> On Tue, Aug 31, 2010 at 10:02 PM, Kitching, Simon
> <Si...@airnz.co.nz> wrote:
> > Hi All,
> >
> > I've got some code using Velocity which failed under load. Can you
> > confirm that the Velocity class is meant to be thread-safe? If so, I'll
> > file a bugreport.
>
> generally, yes, but velocimacro settings can break that. what are
> your velocity properties?
Just setting one property:
Properties p = new Properties();
p.put("velocimacro.permissions.allow.inline.local.scope", "true");
Velocity.init(p);
And interestingly, this *is* what is triggering the problem.
If this property isn't meant to be threadsafe, then it would be good to
at least document it here:
http://velocity.apache.org/engine/devel/developer-guide.html#velocity_configuration_keys_and_values
and maybe the javadoc for the Velocity and VelocityEngine classes should
warn that some properties make the classes non-threadsafe. Though
ideally, they would be threadsafe regardless of property settings..
For now, we've changed our code to use a separate VelocityEngine per
thread, which resolves the issue for us (at some performance cost)..
Oh, and by the way, the archive links to Nabble on this page don't work:
* http://velocity.apache.org/contact.html
They redirect somewhere rather amusing...
Regards,
Simon
Good planets are hard to find - please think of the environment before you print this email.
____________________________________________________________________
CAUTION - This message may contain privileged and confidential
information intended only for the use of the addressee named above.
If you are not the intended recipient of this message you are hereby
notified that any use, dissemination, distribution or reproduction
of this message is prohibited. If you have received this message in
error please notify Air New Zealand immediately. Any views expressed
in this message are those of the individual sender and may not
necessarily reflect the views of Air New Zealand.
_____________________________________________________________________
For more information on the Air New Zealand Group, visit us online
at http://www.airnewzealand.com
_____________________________________________________________________
Re: Re: Velocity class thread-safety problems
Posted by Nathan Bubna <nb...@gmail.com>.
On Wed, Sep 1, 2010 at 3:07 PM, Kitching, Simon
<Si...@airnz.co.nz> wrote:
> Thanks Antonio, Nathan,
>
> I've created JIRA issue:
> https://issues.apache.org/jira/browse/VELOCITY-776
thanks, Simon. if nothing else, we'll make sure the documentation is
updated, but hopefully we can fix this. i can't think of any reason
local inline macros should not be threadsafe.
> On Wed, 2010-09-01 at 07:14 -0700, Nathan Bubna wrote:
>> On Tue, Aug 31, 2010 at 10:02 PM, Kitching, Simon
>> <Si...@airnz.co.nz> wrote:
>> > Hi All,
>> >
>> > I've got some code using Velocity which failed under load. Can you
>> > confirm that the Velocity class is meant to be thread-safe? If so, I'll
>> > file a bugreport.
>>
>> generally, yes, but velocimacro settings can break that. what are
>> your velocity properties?
>
> Just setting one property:
> Properties p = new Properties();
> p.put("velocimacro.permissions.allow.inline.local.scope", "true");
> Velocity.init(p);
>
> And interestingly, this *is* what is triggering the problem.
>
> If this property isn't meant to be threadsafe, then it would be good to
> at least document it here:
>
> http://velocity.apache.org/engine/devel/developer-guide.html#velocity_configuration_keys_and_values
> and maybe the javadoc for the Velocity and VelocityEngine classes should
> warn that some properties make the classes non-threadsafe. Though
> ideally, they would be threadsafe regardless of property settings..
>
> For now, we've changed our code to use a separate VelocityEngine per
> thread, which resolves the issue for us (at some performance cost)..
>
>
> Oh, and by the way, the archive links to Nabble on this page don't work:
> * http://velocity.apache.org/contact.html
> They redirect somewhere rather amusing...
hmm. http://old.nabble.com/Velocity---User-f347.html is what it
ought to have redirected to.
> Regards,
> Simon
>
> Good planets are hard to find - please think of the environment before you print this email.
> ____________________________________________________________________
> CAUTION - This message may contain privileged and confidential
> information intended only for the use of the addressee named above.
> If you are not the intended recipient of this message you are hereby
> notified that any use, dissemination, distribution or reproduction
> of this message is prohibited. If you have received this message in
> error please notify Air New Zealand immediately. Any views expressed
> in this message are those of the individual sender and may not
> necessarily reflect the views of Air New Zealand.
> _____________________________________________________________________
> For more information on the Air New Zealand Group, visit us online
> at http://www.airnewzealand.com
> _____________________________________________________________________
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Re: Velocity class thread-safety problems
Posted by "Kitching, Simon" <Si...@airnz.co.nz>.
Thanks Antonio, Nathan,
I've created JIRA issue:
https://issues.apache.org/jira/browse/VELOCITY-776
On Wed, 2010-09-01 at 07:14 -0700, Nathan Bubna wrote:
> On Tue, Aug 31, 2010 at 10:02 PM, Kitching, Simon
> <Si...@airnz.co.nz> wrote:
> > Hi All,
> >
> > I've got some code using Velocity which failed under load. Can you
> > confirm that the Velocity class is meant to be thread-safe? If so, I'll
> > file a bugreport.
>
> generally, yes, but velocimacro settings can break that. what are
> your velocity properties?
Just setting one property:
Properties p = new Properties();
p.put("velocimacro.permissions.allow.inline.local.scope", "true");
Velocity.init(p);
And interestingly, this *is* what is triggering the problem.
If this property isn't meant to be threadsafe, then it would be good to
at least document it here:
http://velocity.apache.org/engine/devel/developer-guide.html#velocity_configuration_keys_and_values
and maybe the javadoc for the Velocity and VelocityEngine classes should
warn that some properties make the classes non-threadsafe. Though
ideally, they would be threadsafe regardless of property settings..
For now, we've changed our code to use a separate VelocityEngine per
thread, which resolves the issue for us (at some performance cost)..
Oh, and by the way, the archive links to Nabble on this page don't work:
* http://velocity.apache.org/contact.html
They redirect somewhere rather amusing...
Regards,
Simon
Good planets are hard to find - please think of the environment before you print this email.
____________________________________________________________________
CAUTION - This message may contain privileged and confidential
information intended only for the use of the addressee named above.
If you are not the intended recipient of this message you are hereby
notified that any use, dissemination, distribution or reproduction
of this message is prohibited. If you have received this message in
error please notify Air New Zealand immediately. Any views expressed
in this message are those of the individual sender and may not
necessarily reflect the views of Air New Zealand.
_____________________________________________________________________
For more information on the Air New Zealand Group, visit us online
at http://www.airnewzealand.com
_____________________________________________________________________
Re: Velocity class thread-safety problems
Posted by Nathan Bubna <nb...@gmail.com>.
On Tue, Aug 31, 2010 at 10:02 PM, Kitching, Simon
<Si...@airnz.co.nz> wrote:
> Hi All,
>
> I've got some code using Velocity which failed under load. Can you
> confirm that the Velocity class is meant to be thread-safe? If so, I'll
> file a bugreport.
generally, yes, but velocimacro settings can break that. what are
your velocity properties?
> Scenario:
> * Velocity version 1.6.1, java 1.6, linux
> (also fails with velocity-1.6.4)
> * Using a complex template with macros
> * Using a separate context object per thread
> * Invoking Velocity.evaluate(context, out, "", templateText)
>
> Results:
> * Under heavy load from single thread, all ok
> * Under light load from multiple threads, all ok
> * Under heavy load from multiple threads, macro references like
> "#macroname" intermittently don't get invoked during template
> processing; the "#macroname" text appears literally in the output
> instead.
sure sounds like a bug to me.
> Simply replacing calls to
> Velocity.evaluate(...)
> with
> VelocityEngine ve = new VelocityEngine();
> ve.init(props);
> ve.evaluate(...)
> fixes the issue.
>
> I've confirmed the problem with a unit test; I can simplify it and
> submit it if this really is considered a bug.
yes, please.
> >From the documentation, email lists, etc. I believe that using the
> Velocity singleton *should* have worked here (we don't need multiple
> velocity configurations).
>
>
> Comments?
>
> Regards,
> Simon
>
> Good planets are hard to find - please think of the environment before you print this email.
> ____________________________________________________________________
> CAUTION - This message may contain privileged and confidential
> information intended only for the use of the addressee named above.
> If you are not the intended recipient of this message you are hereby
> notified that any use, dissemination, distribution or reproduction
> of this message is prohibited. If you have received this message in
> error please notify Air New Zealand immediately. Any views expressed
> in this message are those of the individual sender and may not
> necessarily reflect the views of Air New Zealand.
> _____________________________________________________________________
> For more information on the Air New Zealand Group, visit us online
> at http://www.airnewzealand.com
> _____________________________________________________________________
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org