[richfaces-issues] [JBoss JIRA] Closed: (RF-4352) Responses processed in different order from original requests.

[Alexander Dubovsky (JIRA)]

     [ https://jira.jboss.org/jira/browse/RF-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Dubovsky closed RF-4352.
----------------------------------



> Responses processed in different order from original requests.
> --------------------------------------------------------------
>
>                 Key: RF-4352
>                 URL: https://jira.jboss.org/jira/browse/RF-4352
>             Project: RichFaces
>          Issue Type: Bug
>    Affects Versions: 3.2.2
>         Environment: Suse Linux: 
> Linux nebula 2.6.18.8-0.9-bigsmp #1 SMP Sun Feb 10 22:48:05 UTC 2008 i686 i686 i386 GNU/Linux
> n
> Jboss 4.2.2.GA
> Seam 2.0.1.GA
> Richfaces 3.2.1.GA
> Firefox 3
>            Reporter: Paul Pantages
>            Assignee: Alexander Dubovsky
>             Fix For: 3.3.0
>
>         Attachments: jboss-seam-booking.ear
>
>
> I modifed Seam booking example for this test.
> I will attach example in jboss-seam-booking.ear
> (1) Deploy the ear file and  point Firefox to 
> http://<YOUR JBOSS IP>:8080/seam-booking
> This should take you to mytabel.seam where  there will be a table and a few buttons.
> The table has 500 rows.
> A poller refreshes the table every 4s or so.
> The poll takes a while to complete as there are so many rows.
> There are some select/unselect buttons, which can be used to select the whole table.
> The select/unselect operations are very quick (compared to the poll).
> There is a status on the RHS that will show "Polling" when the poller is invoked.
> The status on the RHS will show "Working" when buttons are pressed.
> (2) Watch the status for a while and make sure the poller is running. Let it go a few polls to make sure it is working.
> (3) When the poller is running, as evidenced by the "Polling" status msg., press the SELECT_ALL button. 
> When the SELECT_ALL operation completes, the table is not re-rendered, but the row styles are modified by to reflect that the "select all" request is complete. 
> This is done by an oncomplete event handler on the button.
> (4) Watch the status and you should see that the select operation completes before the poll completes, and the table is "selected".
> (5) Watch the status to see the poll complete. The table is rerenderd and the rowStyles are re-written. The table appears "unselected", as the poll was processed,by the server, before the select operation
> (6) If you wait for another poll, the table will be rendered and properly selected.
> It appears that the response for the poll was processed after the select response.
> (7) Check the Log: If you tail the log file:
>      tail -F ../logs/debug.log|grep myTable
> You will see some logs like this, and can tell whether the poll was processed before the 
> select/unselect button or vice versa. The "get ajaxRenderList" trace indicates the poll
> was processed before "unselect all"
> Client: [myTable] get ajaxRenderList mainPanel 
> Client: [myTable] get rowClasses
> Client: [myTable] unselect all
> ....
> This shows that the requests have bee processed in the proper order. 
> (8) If you click the toggle alerts, an alert will pop up for the onbeforedomupdate event on the poller and select buttons. Repeat 1-6 .This can be used to verify that event for the buttons occurs before the poll, when the requests were made in the opposite order.
> (9) If necessary the page size can be adjusted 0-1000 to make the problem easier to reproduce. Dep on the performance of your host.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira