[jira] [Assigned] (WICKET-4668) Ajax responses for QUEUE and DROP type channels are not guaranteed to be processed in the order of the requests

["Martin Grigorov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov reassigned WICKET-4668:
---------------------------------------

    Assignee: Martin Grigorov
    
> Ajax responses for QUEUE and DROP type channels are not guaranteed to be processed in the order of the requests
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-4668
>                 URL: https://issues.apache.org/jira/browse/WICKET-4668
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 6.0.0-beta3
>            Reporter: Christian Oldiges
>            Assignee: Martin Grigorov
>
> The ajax responses are processed in several recorded steps depending on the response content. Those steps form a step-chain for each request/response. The processing order of each step-chain is guaranteed to be processed in the correct order but having several of those step-chains being executed "concurrently" may result in out-of-order response processing.
> The "concurrency" is introduced into the response processing by using the window.setTimeout function to re-schedule some of the steps (for various reasons), but this timeout function does NOT guarantee to execute the scheduled code in the order it is scheduled.
> For this reason e.g. the DOM replacement step of response2 might be executed before the same step is executed for response1.
> This effect is also visible to the user. Suppose you have a textfield and you trigger an ajax-request for each new character in the textfield (onChange event). The Ajax response updates another part of the page showing the entered text in a label component. Now, if the out-of-order response processing hits, the label might show an old state of the textfield, because the latest response has been overwritten by a previous response.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira