[jira] [Comment Edited] (WICKET-5588) Mixing Ajax and push (Atmosphere/native-websockets) updates does not respect order

["Daniel Stoch (JIRA)" <ji...@apache.org>]

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

Daniel Stoch edited comment on WICKET-5588 at 3/9/17 7:57 AM:
--------------------------------------------------------------

I am still trying to resolve this problem (my local patch does not work in all cases). So for now I see 2 possible solutions, which Emond described earlier:
1. Use the same websocket connection for ajax updates.
2. Ordering responses (which requires solving such problems as: lost responses, timeouts, maybe some kind of redelivery, etc...).

I have look again on your patch Martin (solution 1):
{quote}
I've implemented Emond Papegaaij's idea of pushing the Ajax response via the WebSocket connection.
{quote}

As I said in my previous comment this does not work well for me. But now I have change this implementation getAjaxRequestTargetProvider() method to have much simpler "if" condition:
{code}
 if (connection != null) {
  target = new WebSocketRequestHandler(context, connection);
} else {
  target = new AjaxRequestHandler(context);
}
{code}
And it looks promising (I must do more tests).

I have a couple of questions:
1. Why in your example patch you have wrapped WebSocketRequestHandler (ws) inside AjaxRequestHandler, and you do not return ws directly?
2. ws.respond() call is inside detach() method - what is the reason of this (maybe it is a source of my problems when I tested this solution for the first time last year)?
3. Currently I have found an issue that listeners (IListener) does not work - this is natural because it is not implemented in WebSocketRequestHandler. What do you think to add such implementation (as it is in AjaxRequestHandler)?


was (Author: interface):
I am still trying to resolve this problem (my local patch does not work in all cases). So for now I see 2 possible solutions, which Emond described earlier:
1. Use the same websocket connection for ajax updates.
2. Ordering responses (which requires solving such problems as: lost responses, timeouts, maybe some kind of redelivery, etc...).

I have look again on your patch Martin:
{quote}
I've implemented Emond Papegaaij's idea of pushing the Ajax response via the WebSocket connection.
{quote}

As I said in my previous comment this does not work well for me. But now I have change this implementation getAjaxRequestTargetProvider() method to have much simpler "if" condition:
{code}
 if (connection != null) {
  target = new WebSocketRequestHandler(context, connection);
} else {
  target = new AjaxRequestHandler(context);
}
{code}
And it look promising (I must do more tests).

I have a couple of questions:
1. Why in your example patch Martin you have wrapped WebSocketRequestHandler (ws) inside AjaxRequestHandler, and you do not return ws directly?
2. ws.respond() call is inside detach() method - what is the reason of this (maybe it is a source of my problems when I tested this solution for the first time)?
3. Currently I have found an issue that listeners (IListener) does not work - this is natural because it is not implemented in WebSocketRequestHandler. What do you think to add such implementation (as it is in AjaxRequestHandler)?

> Mixing Ajax and push (Atmosphere/native-websockets) 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, wicket-native-websocket
>    Affects Versions: 6.15.0, 6.21.0
>            Reporter: Daniel Stoch
>            Assignee: Emond Papegaaij
>         Attachments: 5588-ajax-thru-websocket.tgz
>
>
> 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.15#6346)