1 Mar
2017
1 Mar
'17
9:04 a.m.
Hi,
On 28 Feb 2017, at 23:25, ktc
<ktc-wiki(a)amazon.com> wrote:
That extension is on the right track to what we would need, unfortunately it
only works for groovy.
I wasn't thinking that it would have to be at the JVM level but maybe at the
rendering context level or context level in general? The context could then
can keep track of how deeply nested the inclusions are as well as keep track
of how long the request has been running. These limits can then be checked
at critical times while rendering is occurring and then throw an Exception
to abort the process should a limit be broken. It wouldn't necessarily have
to guarantee 100% accuracy in the first iteration of the feature, but a best
effort could be good for some protection.
If you check the groovy pas I linked to in my first response you’ll see that the limiter
will fail as soon as a java api is called so indeed there’s no way to guarantee a response
time.
Now back to what you mentioned above, the only loop that would make sense is the
MacroTransformation component since macros are what could take time (especially the script
macros). So yes, it would be possible to stop the rendering there (i.e. stop evaluating
transformations when they take too much time). Actually we already have a protection there
to avoid infinite cycle (a macro generating itself).
That’s certainly doable and not too hard but you need to understand that it wouldn’t
guarantee anything. Could you please raise a jira issue for this idea so that it’s
recorded and if anyone has an interest in implementing it they can find the idea?
Thanks
-Vincent
--
View this message in context:
http://xwiki.475771.n2.nabble.com/Page-Complexity-limiter-tp7602880p7602882…
Sent from the XWiki- Dev mailing list archive at Nabble.com.