I have checked wicket-ajax-jquery.js file history and as I supposed the "process" method was added to support Atmosphere push calls in Wicket. See the commit (for issue: WICKET-4668): https://github.com/apache/wicket/commit/130b063722e55510f2b2a3b47889e14210a5a32f This method can cause out-of-order response processing.
So the problem still exists (eg. in such scenario I've described in previous e-mail). Maybe it is the same one as described in WICKET-4668 or something very similar to it. Create a new issue for this? -- Daniel On Thu, May 8, 2014 at 10:32 AM, Daniel Stoch <[email protected]> wrote: > Hi, > > I have a problem with refreshing a component (panelA) via ajax request > when two different threads in the "same" time perform such refreshing > (Wicket 6.15.0). > 1. The first thread (thread1) is a standard servlet container thread > to handle user request from a browser: > - user clicks AjaxLink and on onClick method panelA is refreshed by > target.add(panelA). > 2. The second thread (thread2) is a notification from a backend system > which causes a panelA refreshing too: > - it can be done for eg. using Atmosphere integration by > EventBus.post() - panelA is refreshed by target.add(panelA) too. > > On the server side only one thread can access a page at a time so > everything is "queued" properly: the thread1 panelA refresh is > executed, then the thread2 refresh code is fired. > > But it looks like on the client side the order of ajax calls is > undefined: sometimes JS code added from the thread1 is executed as > first, sometimes as a second one. On my computer this order almost > always is wrong. It leads to an incorrect situation when the component > state on a server is different than the DOM tree on the client browser > (so for example user can clicks not existing link). > > As far as I know in Wicket ajax calls by default using the same > channel and they are queued. So everything should work ok. But in my > scenario in the thread2 on the client side the refreshing is done by > calling (wicket-atomosphere.js): > Wicket.Ajax.process(response.responseBody); > > Does this call uses this queuing/channels mechanism or maybe this call > bypasses it? Maybe it is a bug in wicket-atmosphere integration, but > my question is more general: how it should be done to ensure that JS > ajax calls on the client side have the same order as on the server > side? > > -- > Best regards, > Daniel
