[
https://issues.apache.org/jira/browse/WICKET-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092188#comment-15092188
]
Daniel Stoch commented on WICKET-5588:
--------------------------------------
{quote}
There is no way how to stop/enqueue an Ajax request and wait for the WS to
serve its response, because you don't know when a WS push will be done.
{quote}
So why above patch works for me? :) Is it a problem only with using different
channel name or something more general?
Beside this: what are the common use cases to use different channel for ajax
request? I don't remember I was ever using this in my apps.
I have done a fast test in my app using your attached implementation of pushing
the Ajax response via the WebSocket connection. And quick answer is: not
everything works ok as in standard AjaxRequestHandler. And it would be very
difficult to make quickstarts for these problems, because they can be very
specific to my framework :(.
Examples:
- modal windows (I am using Bootstrap modal JS) does not always close,
- DataView is not refreshed when adding/removing objects from underlying
collection,
- some JQuery effects stop working (highlights, fade outs): they are added to
AjaxRequestTarget using append/prependJavaScript, some of them use "notify|..."
syntax,
- in one situation I have an infinie loop of ajax requests.
> 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.4#6332)
