[jira] [Commented] (WICKET-5588) Mixing Ajax and Atmosphere updates does not respect order

["Emond Papegaaij (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997870#comment-13997870 ] 

Emond Papegaaij commented on WICKET-5588:
-----------------------------------------

I agree, it would be nice if Wicket could handle this, but as I said before, it will be hard to implement. IMHO the best way would be to let ajax update use the WS-connection. The connection is already open, why not reuse it for ajax updates? Ordering of updates will be handled by the server and because there's only one communication channel, updates cannot get out-of-order. The problem however is that the js performing ajax updates is not very modular. I've looked at this, but didn't see an easy way to replace the communication layer without rewriting most of the script. Perhaps Martin Grigorov knows a way?

> 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.2#6252)