[ https://issues.apache.org/jira/browse/WICKET-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emond Papegaaij closed WICKET-6861. ----------------------------------- Resolution: Won't Fix Closing this issue. I've tried several solutions and came to the conclusion that this one is very hard to fix in a general way. For our application, we now set a data attribute on the document when the timer should stop and check this attribute in a precondition. That works 100% reliable but will be impossible to convert into a general solution for all Wicket users. > Possible race condition in clearing and triggering of Wicket timers > ------------------------------------------------------------------- > > Key: WICKET-6861 > URL: https://issues.apache.org/jira/browse/WICKET-6861 > Project: Wicket > Issue Type: Bug > Components: wicket-core > Affects Versions: 9.2.0 > Reporter: Emond Papegaaij > Priority: Minor > > In our test suite we see some intermittent failures related to > {{AbstractAjaxTimerBehavior}}. At a few places in our application, we use a > background poller at a 1 sec interval that checks for an out-of-band > submission of the form data. So the user either has to fill the form via the > web interface or via some other route. Either route can complete the form, > but as soon as one of the two is triggered, the other must stop. The race > condition lies in the {{AbstractAjaxTimerBehavior}} triggering while the user > has already submitted the form manually. > The naive implementation would stop {{AbstractAjaxTimerBehavior}} via > {{Wicket.Timer.clear('timer0')}} in the Ajax response of the form submit. > However, this results in a very large gap between the moment of submission > and the actual moment the timer is stopped. To fix this, we've added the > following code to the {{AjaxSubmitLink}}: > {code:java} > @Override > public void renderHead(IHeaderResponse response) { > super.renderHead(response); > response.render(OnDomReadyHeaderItem.forScript( > "Wicket.Event.add('" + getMarkupId() + "', 'click', " + > "function() {Wicket.Timer.clear('" + getTimerId() + "');})")); > } > {code} > This puts the call to {{Wicket.Timer.clear}} before the actual Ajax submit > and should therefore prevent the timer from triggering after the Ajax submit > is done. However, in very rare occurrences we still see the timer triggering. > When it happens, the timer is always directly after the Ajax submit (often > within 10ms). This makes us believe the current implementation has a race > condition in the following way: > * The user clicks the Ajax submit link > * The execution of the event handlers is started in the browser > * At this moment the {{setTimeout}} triggers, but it is suspended because JS > is single threaded and the browser is already execution JS in response to UI > interaction > * The first event handler now clears the timer > * The second event handler performs the Ajax call > * Now the JS executor is freed and the timer function is executed > Although I'm not entirely at home in the execution model of JS in a browser, > this is the only explanation I could come up with. There is no way to > reproduce it, other than run a complex test suite 1000ths of times. My > proposed fix is to replace the timeout function in {{wicket-ajax-jquery.js}} > in {{Wicket.Timer.set}} with this: > {code:javascript} > Wicket.TimerHandles[timerId] = setTimeout(function() { > if (timerId in Wicket.TimerHandles) { > Wicket.Timer.clear(timerId); > f(); > } > }, delay); > {code} > This should prevent the function {{f()}} to be executed after the timer has > been cleared (Wicket.Timer.clear deletes the {{timerId}} from > {{Wicket.TimerHandles}}. -- This message was sent by Atlassian Jira (v8.3.4#803005)