Concurrent ajax request to the same page - ordering problem (Atmosphere related)

[Daniel Stoch <da...@gmail.com>]

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

Re: Concurrent ajax request to the same page - ordering problem (Atmosphere related)

[Daniel Stoch <da...@gmail.com>]

WICKET-5588

On Fri, May 9, 2014 at 9:11 AM, Daniel Stoch <da...@gmail.com> wrote:
> I have checked wicket-ajax-jquery.js file history and as I supposed
> the "process" method was added to support Atmosphere push calls in
> Wicket. See the commit (for issue: WICKET-4668):
> https://github.com/apache/wicket/commit/130b063722e55510f2b2a3b47889e14210a5a32f
> This method can cause out-of-order response processing.
>
> So the problem still exists (eg. in such scenario I've described in
> previous e-mail). Maybe it is the same one as described in WICKET-4668
> or something very similar to it.
> Create a new issue for this?
>
> --
> Daniel
>
cut

Re: Concurrent ajax request to the same page - ordering problem (Atmosphere related)

[Daniel Stoch <da...@gmail.com>]

I have checked wicket-ajax-jquery.js file history and as I supposed
the "process" method was added to support Atmosphere push calls in
Wicket. See the commit (for issue: WICKET-4668):
https://github.com/apache/wicket/commit/130b063722e55510f2b2a3b47889e14210a5a32f
This method can cause out-of-order response processing.

So the problem still exists (eg. in such scenario I've described in
previous e-mail). Maybe it is the same one as described in WICKET-4668
or something very similar to it.
Create a new issue for this?

--
Daniel

On Thu, May 8, 2014 at 10:32 AM, Daniel Stoch <da...@gmail.com> wrote:
> 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