[ https://issues.apache.org/jira/browse/WICKET-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919538#comment-13919538 ]
Martin Grigorov commented on WICKET-5243: ----------------------------------------- Thanks for testing, Guillaume! I will clean and document the new functionality and push it. It will be part of 6.15. > 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, > WICKET-5243-notify-only-when-async.patch, response.xml, wicket-ajax-jquery.js > > > 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 was sent by Atlassian JIRA (v6.2#6252)