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
