[
https://issues.apache.org/jira/browse/VELOCITY-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905371#action_12905371
]
Nathan Bubna commented on VELOCITY-776:
---------------------------------------
Ok, RuntimeInstance dumps the vm namespace for a template before parsing it.
It does this under the assumption that if you are reparsing the template, it
must have changed. If it changed, we shouldn't keep local macros around, as
they may no longer exist in the new version. This still seems to me that
correct behavior. When rapidly (re)parsing the same template in multiple
threads, this means that thread B may dump the namespace newly created and not
yet used in rendering by thread A.
This unfortunate event can be avoided by permanently caching templates, or
greatly reduced in likelihood by caching them with an infrequent
modificationCheckInterval. Though, even there it is possible, i think.
So, here's the choices i've thought of thus far:
1) leave it and add disclaimers about inline macros when templates aren't
permanently cached
2) we can flip the bit and risk memory leakage (and potential interference)
from stale macros
3) add another config switch to let users choose between #1 and #2
4) synchronize creatively to prevent simultaneous parsing and/or rendering in
the same namespace
5) try to find a way to refactor so inline macros are kept with the template,
not managed centrally
#5 is more than i can take on right now, and probably won't work for the 1.x
branch. maybe in 2.x
#4 would probably both wreck performance and never quite work right
#3 is tiresome, but probably the best current option
#2 would probably only be terrible for people with users creating templates,
but could be quite the memory leak for them
#1is arguably acceptable for 1.7, but is not a long-term solution
thoughts?
> "velocimacro.permissions.allow.inline.local.scope" makes VelocityEngine not
> threadsafe
> --------------------------------------------------------------------------------------
>
> Key: VELOCITY-776
> URL: https://issues.apache.org/jira/browse/VELOCITY-776
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.6.4
> Environment: Sun java jdk1.6.0_21, Ubuntu 10.04
> Reporter: Simon Kitching
> Attachments: RenderVelocityTemplate.java,
> RenderVelocityTemplateTest.java
>
>
> The attached unit test shows that when
> "velocimacro.permissions.allow.inline.local.scope" is set to true, and
> multiple threads use the same VelocityEngine instance then macros sometimes
> don't get expanded and the #macroname call remains in the output text.
> Notes:
> * running test method "testMultipleEvals" (single threaded case) always
> succeeds
> * running test method "testMultiThreadMultipleEvals" always fails
> * commenting out the allow.inline.local.scope line makes the multithread test
> pass (but of course has other side-effects)
> Interestingly, for the multithread case it seems that 1 thread always
> succeeds and N-1 threads fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
