[jira] Closed: (SLING-601) Request Inclusion Counter operating too rigid

["Felix Meschberger (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger closed SLING-601.
-----------------------------------

    Resolution: Fixed

There was a small bug in the callCounter handling the RequestData.service method, which caused the max Call limit to never be reached since, the counter was decremented after the call. This is wrong and the counter is now not decremented any more. This also ensures the counter value in the timer name has a sensible and unique value.

Fixed in Rev. 738529.

In Rev. 738531 I added an integration test for the max call limit check, which in fact revealed the issue the RequestData.service method.

> Request Inclusion Counter operating too rigid
> ---------------------------------------------
>
>                 Key: SLING-601
>                 URL: https://issues.apache.org/jira/browse/SLING-601
>             Project: Sling
>          Issue Type: Bug
>          Components: Engine
>    Affects Versions: Engine 2.0.2
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: Engine 2.0.4
>
>
> The SlingMainServlet implements a recursion level counter to prevent recursions going too deep in the checkRecursionLevel method. What this method does is incrementing a counter stored as a request attribute everytime RequestDispatcher.include is called (by whatever means).
> The drawback of this mechanism is, that the counter is only incremented and never decremented after an inclusion returns. This in fact is not a recursion level counter but a counter limiting the number of times RequestDispatcher.include may be called. Another drawback of this is, that the implementation is overcomplicated, because the RequestData object created for each request keeps a stack of a inclusions and hence could easily implement a real recursion level checker by just checking the size of the stack.
> I think, we should drop the SlingMainServlet.checkRecursionLevel method altogether and replace it with a new RequestData.checkAbort method which throws in case any of two cases occurrs:
>    * Recursion Level is too deep (50 seems like useful)
>    * Number of includes exceeds a given number (something like 1000 or more ?)
> In addition the Exception should be made public in the Sling engine module such that users of any include mechanism could handle it if need be.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.