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

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.