[ https://issues.apache.org/jira/browse/WICKET-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081181#comment-15081181 ]
Daniel Stoch commented on WICKET-5588: -------------------------------------- The same problem exists when I am using wicket-native-websocket implementation instead of Atmosphere. The similar patch works for me for 6.21.0: {code} process: function(data) { var context = { attrs: {}, steps: [] }; this._initializeDefaults(context.attrs); var res = Wicket.channelManager.schedule(context.attrs.ch, Wicket.bind(function () { this.channel = context.attrs.ch; var xmlDocument = Wicket.Xml.parse(data); this.loadedCallback(xmlDocument, context); var executer = new FunctionsExecuter(context.steps); executer.start(); this.done(context.attrs); }, this)); return res !== null ? res: true; }, {code} > Mixing Ajax and Atmosphere updates does not respect order > --------------------------------------------------------- > > Key: WICKET-5588 > URL: https://issues.apache.org/jira/browse/WICKET-5588 > Project: Wicket > Issue Type: Improvement > Components: wicket, wicket-atmosphere > Affects Versions: 6.15.0 > Reporter: Daniel Stoch > Assignee: Emond Papegaaij > > As far as I know in Wicket ajax calls by default using the same channel and > they are queued. But in wicket-atmosphere integration on the client side the > refreshing is done by calling (inside wicket-atomosphere.js): > Wicket.Ajax.process(response.responseBody); > It looks like Wicket.Ajax.process() function does not use channels > management, so it can result in out-of-order response processing. This method > was added to support Atmosphere push calls in Wicket. See the commit (for > issue: WICKET-4668): > https://github.com/apache/wicket/commit/130b063722e55510f2b2a3b47889e14210a5a32f > *Example scenario to reproduce this problem:* > When we try to refresh a component (panelA) via ajax when two different > threads in the "same" time perform such refresh. > 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). -- This message was sent by Atlassian JIRA (v6.3.4#6332)