Hi, > On 28 Feb 2017, at 23:25, ktc <[email protected]> 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.html > Sent from the XWiki- Dev mailing list archive at Nabble.com.
