1 2 Previous Next 15 Replies Latest reply on Sep 5, 2007 12:17 PM by sergeysmirnov

    Ajax4jsf flooding and conversation resetting

    damianharvey

      There is a thread and associated JIRA in the Seam forum that would be great if one of the Ajax4JSF guys could join. It concerns how a Seam conversation is killed by Ajax4jsf - was when validating (fixed) but also with flooding (not fixed).

      [ur]http://jboss.com/index.html?module=bb&op=viewtopic&p=4080026#4080026[/url]
      http://jira.jboss.com/jira/browse/JBSEAM-1832

      Cheers,

      Damian.

        • 1. Re: Ajax4jsf flooding and conversation resetting

          There are two points here:
          1. Working in multi-thread mode
          2. Flood protection

          1 Looks like a task for Seam

          2. RichFaces (Ajax4jsf) has a flood protection feature when only one request is sent to the server. Another request will wait until the response from the first request is completed. To turn this feature on, developer have to define the a queue name explicitly for the ajax component that might, potentially, send simultaneous requests

          • 2. Re: Ajax4jsf flooding and conversation resetting
            damianharvey

            2. This doesn't work or at least doesn't work without killing the Seam conversation (which to a Seam user is essentially the same).

            See the referenced Seam forum thread. I have put some code towards the end of that where I use eventsQueue="calc". This does nothing to help prevent the 'flood'.

            Thanks,

            Damian.

            • 3. Re: Ajax4jsf flooding and conversation resetting

              we will see

              • 4. Re: Ajax4jsf flooding and conversation resetting
                damianharvey

                Thanks Sergey. Your help is very much appreciated as we are having to be rather delicate with ajax4jsf on our pages at the moment due to this issue.

                Cheers,

                Damian.

                • 5. Re: Ajax4jsf flooding and conversation resetting
                  damianharvey

                  Update to this. It looks like if you have a page with an active Seam conversation then any delay in processing the ajax4JSF action will kill the conversation. This is reproducible. Please see the JIRA and associated post for more.

                  Cheers,

                  Damian.

                  • 6. Re: Ajax4jsf flooding and conversation resetting
                    pmuir

                    My conclusion having looked at this is that ignoreDupResponses is causing a problem as it appears it doesn't abort the current call, hence we end up with concurrent calls in Seam (we are also looking at improving handling of concurrent calls in Seam). Any ideas why this is a problem? I can probably provide an example if it helps.

                    • 7. Re: Ajax4jsf flooding and conversation resetting

                      aborting the request is not a job for ignoreDupResponses. The purpose of it is only avoid unnecessary DOM update if the next similar request is sent to the server.
                      JSF lifecycle is not transactional, in general. Attempt to abort the previous request might cause unpredictable result.

                      • 8. Re: Ajax4jsf flooding and conversation resetting
                        pmuir

                        Ok, I think the docs should be updated to reflect this

                        ignoreDupResponses - If true, unfinished request will be aborted on new event.


                        doesn't read (to me) as what you've just told me. I'll update my new section in the Seam docs to explicitly tell people to avoid using ignoreDupRequests with Seam conversational components.

                        Whilst we're discussing this - there is no way to timeout events on the queue i.e. to say - if event X has been on the queue > 500ms discard it. If I'm reading the docs correctly requestDelay doesn't discard events, it just delays them.

                        • 9. Re: Ajax4jsf flooding and conversation resetting

                          I have dedicated the whole section to the Ajax attributes in the new upcoming richfaces-demo. I hope, it will help to people (including the ones who write our doc).

                          Those are quotes from there:
                          ignoreDupResponses attribute orders to ignore the Ajax Response produced by the request if the newest 'similar' request is in a queue already. ignoreDupResponses="true" does not cancel the request while it is processed on the server, but just allows to avoid unnecessary updates on the client side if the response loses the actuality.
                          requestDelay attribute defines the time (in ms.) that the request will be wait in the queue before it is ready to send. When the delay time is over, the request will be sent to the server or removed if the newest 'similar' request is in a queue already .

                          • 10. Re: Ajax4jsf flooding and conversation resetting
                            pmuir

                            Thank you Sergey - most enlightening!

                            • 11. Re: Ajax4jsf flooding and conversation resetting
                              pmuir

                              Ok, I've been thinking some more.

                              1) With ignoreDupResponses are requests still completely serialized or can a request be sent to the server before a response is received (I think I was seeing a request being sent before a response was received)

                              2) requestDelay doesn't play nicely with Seam's conversation context - specifically that after the timeout the event is sent anyway. It would work much better with Seam (AFAICS) if the request was dropped at this point. However I can also see problems with this approach - that we are dropping requests.

                              • 12. Re: Ajax4jsf flooding and conversation resetting
                                alexsmirnov

                                eventsQueue option for a AJAX components was added to reduce number of requests for a frequently events. Really, this is very simple solution - new events is dropped during request processing ( or, with a ignoreDupResponse attribute set tu true, cancel unfinished request and start new one ).
                                Peter, how I can change client-side behavior for a better support of a Seam concurrent processing ?

                                • 13. Re: Ajax4jsf flooding and conversation resetting

                                  We have some items in TODO list regarding enhancements for queue functionality. This is planning as task that should start right after 3.1.0 GA.





                                  • 14. Re: Ajax4jsf flooding and conversation resetting
                                    pmuir

                                    I'm still thinking about what client side support (and changes to Seam) we can make to get this working more smothly - we need to get others (especially Gavin's) input on this as well. I added this yesterday about using ajax with conversations - hopefully it explains in detail the mechanisms we use in Seam and also what to watch out for when using richfaces:

                                    http://fisheye.jboss.org/browse/JBoss/jboss-seam/doc/reference/en/modules/conversations.xml?r1=1.34&r2=1.35

                                    Is there a copy of this todo list somewhere - I'm interested to see your plans.

                                    1 2 Previous Next