[jira] [Commented] (WICKET-5243) JS: High stack size in Function Executor causes "too much recursion"

["Martin Grigorov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688996#comment-13688996 ] 

Martin Grigorov commented on WICKET-5243:
-----------------------------------------

> why 1000 ?
See https://issues.apache.org/jira/browse/WICKET-4675?focusedCommentId=13426609&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13426609
It is a random number that most of the browsers can handle. But it depends on how much data is in each stack frame ...

There is problem with your assumption that you should not wait when components are changed and JS is executed.
The contract is:
1) load all header contributions. This is needed because a script in prependJavaScript may need some library to do its job
2) execute prependJavaScript scripts
3) replace the components
4) execute all OnDomReady, OnLoad and OnEvent header contributions
5) execute all appendJavaScript scripts

prependJS and appendJS scripts are combined in one step (See WICKET-4675), so this shouldn't be the problem in your case.
I guess you don't have hundreds of header contributions so probably you have many components to be replaced ?!

Can you copy the Ajax response when you face this problem and attach it to the ticket so we can investigate what is the reason ?
                
> JS: High stack size in Function Executor causes "too much recursion"
> --------------------------------------------------------------------
>
>                 Key: WICKET-5243
>                 URL: https://issues.apache.org/jira/browse/WICKET-5243
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 6.8.0
>         Environment: Tested on Firefox
>            Reporter: Tobias Haupt
>              Labels: javascript, perfomance
>         Attachments: WICKET-5243-avoid-recursion.patch
>
>
> The Function Executor in wicket-ajax-jquery.js uses recursion and deferred calls to the notify() function to ensure synchronous execution of all tasks contained in an AjaxResponse.
> Each task calls notif() when it is finished. This causes a recursive call to processNext() thus raising the stack for each execution. If there are a lot of task to handle, the stack size will increase beyond the possible stack size in the client causing a "too much recursion" exception and increasingly low performance.
> The deferred execution of notify is only necessary if the task executor has to wait for long running tasks to finish at some uncertain point in the future. Examples: downloading of external resources (js, css, images). These task can call back the executor as soon as they are really finished (e.g. load event triggerd).
> The problem is that the majority of tasks don't need to wait but return instantly instead. Examples: exchanging components, executing custom javascripts that do not use the "|-syntax" to include the notify callback.
> Current fix: The depth of the stack is counted and if a depth of >= 1000 is reached, a timeout will interrupt the synchronous task queue execution. A new executor will continue with an empty stack.
> Problems with that approach: 
> - why 1000?
> - several ajax requests might interrupt each other because the synchronous execution is broken.
> - if an executed custom javascript creates a big stack itself (e.g. by using jquery a lot) the stack will add to the stack used by the Function Executor so that it may still be too big.
> Proposal to fix this: see also the attached patch.
> Another callback notifyContinue() is supported that can be called whenever the task will return instantly. This callback avoids the recursive call to processNext and continues in a simple loop over all the tasks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira