You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Daniel Stoch (JIRA)" <ji...@apache.org> on 2014/05/14 10:59:16 UTC

[jira] [Comment Edited] (WICKET-5588) Wicket.Ajax.process() function does not use channels

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

Daniel Stoch edited comment on WICKET-5588 at 5/14/14 8:59 AM:
---------------------------------------------------------------

{quote}
Preventing mixed updates is not that hard. If a component is updated via atmosphere pushes, simply never add it to the AjaxRequestTarget of an ajax request, but trigger an event instead. If a client triggers an update of a panel, it will not receive the panel as response of the ajax call, but via a pushed update.
{quote}
In same cases it is simple but in general it is not. I don't know how to write such global condition: when not to add a panel to ajax request target? For example you have a panelA which is updated in code by ajax request. Then you or another user what to use it on another panel or page (so panelA became a child component). Such another panel can have its own logic and updates on atmosphere pushes. You cannot modify panelA logic, so how to avoid its update? I can provide more examples where it will be very hard to prevent mixing updates. We should not move responsibility to the user (developer) to decide whether panel can be added to ajax request target or not (the code became unnecessary complicated). If such updates cannot be mixed it must be handled automatically by a framework or (better) they should be allowed and framework should handles them transparently to the user.



was (Author: interface):
{quote}
Preventing mixed updates is not that hard. If a component is updated via atmosphere pushes, simply never add it to the AjaxRequestTarget of an ajax request, but trigger an event instead. If a client triggers an update of a panel, it will not receive the panel as response of the ajax call, but via a pushed update.
{quote}
In same cases it is simple but in general it is not. I don't know how to write such global condition: when not to add a panel to ajax request target? For example you have a panelA which is updated in code by ajax request. Then you or another user what to use it on another panel or page (so panelA became a child component). Such another panel can have its own logic and updates on atmosphere pushes. You cannot modify panelA logic, so how to avoid its update? I can provide more examples where it will be very hard to prevent mixing updates. We should not move responsibility to the user (developer) to decide whether panel can be added to ajax request target or not. If such updates cannot be mixed it must be handled automatically by a framework or (better) they should be allowed and framework should handles them transparently to the user.


> Wicket.Ajax.process() function does not use channels
> ----------------------------------------------------
>
>                 Key: WICKET-5588
>                 URL: https://issues.apache.org/jira/browse/WICKET-5588
>             Project: Wicket
>          Issue Type: Bug
>          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)