10 Replies Latest reply on May 14, 2007 5:11 PM by reind

    Conversation processing another request error when using A4J

    reind

      I have a simple "select country" selectOneMenu. I'm using a4j:support to re-render a province/state/region field based on my selection of country. I'm experiencing "conversation processing another request" errors if I change my country selection too quickly.

      Here's my view code:

      <h:selectOneMenu value="#{.country}">
       <f:selectItems value="#{.countries}"/>
       <a:support event="onchange" reRender="..." ajaxSingle="true" />
      </h:selectOneMenu>


      If I quickly tabin-select country-tabout then tabin-select country-tabout and repeat this fast enough I will get error stating that the conversation has timed out or was processing another request (I assume in this case the latter is the issue).

      Anyone have any ideas of how to resolve this?

      Thanks.

        • 1. Re: Conversation processing another request error when using
          christian.bauer

          I get the same with a:support and the keypress event in a textarea. What it looks like is that we need to get A4JSF to queue events instead of sending them in parallel. I'm not sure how to do that, guess we better ask the folks in the A4JSF forum.

          • 2. Re: Conversation processing another request error when using
            pmuir

            Do the eventsQueue and requestDelay attributes not help? From what I've seen they should both be set by default...

            • 3. Re: Conversation processing another request error when using
              reind

               

              "petemuir" wrote:
              Do the eventsQueue and requestDelay attributes not help? From what I've seen they should both be set by default...


              I've not set either of these myself. My understanding, as well, was that they were set by default.

              requestDelay Delay ( in ms. ) for send ajax request on JavaScript event. In conjunction with events queue can reduce number of requests on keyboard or mouse move events.

              eventsQueue Name of requests queue to avoid send next request before complete other from same event. Can be used to reduce number of requests of frequently events ( key press, mouse move etc ).


              The other interesting one is:

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


              I'll try the a4j forums, see if they have any ideas.

              • 4. Re: Conversation processing another request error when using
                pmuir

                Sorry, bad use of English on my part there. What I was trying to say was that currently you, the developer, has to set them for each a:support and that, IMO, they ought change it so that they are set by default. Try setting them as inidicated in the manual.

                • 5. Re: Conversation processing another request error when using

                   

                  "reind" wrote:

                  I've not set either of these myself. My understanding, as well, was that they were set by default.


                  By default, the queue is not specified and delay is not specified as well. In this case, nothing stops ajax requests to be sent immediately just after events occur.
                  Having parallel requests might be stressful for server, especially in case of JSF 1.1. So, this was one of the motivations why we added requestDelay attribute later. Another motivation was to avoid useless activity on the server and client (when you type something - no reason to send and process previous non actual requests)

                  Even you specify only requestDelay, the mechanism starts to work. The queue with name equals id of the parent component is created implicitly (by default - no queue at all)

                  • 6. Re: Conversation processing another request error when using
                    reind

                    This problem does not happen on non-conversational pages. I'm hoping there's a better solution than trying to set the requestDelay high enough to avoid issues.

                    The problem with that approach is that the proper value for requestDelay depends on the responsiveness of the server (which depends on load, hardware, etc).

                    Would there be a way for seam to handle this more gracefully?

                    • 7. Re: Conversation processing another request error when using
                      cwash

                       

                      The problem with that approach is that the proper value for requestDelay depends on the responsiveness of the server (which depends on load, hardware, etc).

                      Would there be a way for seam to handle this more gracefully?


                      This is an interesting question, if it's only a conversation causing issues... The only other alternative to blocking requests while one is currently processing in a conversation (which is more or less the point of having a conversation in the first place) would be to be able to configure the conversation to abandon a currently processing request if a new one comes in. I think that might be opening a big can of worms -- first from a security perspective, and it may even change notions and definitions of what conversations are and how they should behave. Or did you have something else in mind?

                      • 8. Re: Conversation processing another request error when using
                        reind

                         

                        "cwash" wrote:
                        ... would be to be able to configure the conversation to abandon a currently processing request if a new one comes in.


                        That's about what I was thinking. I haven't thought through the ramifications though and I'm not sure how doable it is.

                        Another alternative would be for A4J to just queue any new requests until the response has been received and only then send the newest request (discarding all those in the middle).

                        • 9. Re: Conversation processing another request error when using
                          cwash

                           

                          "reind" wrote:
                          Another alternative would be for A4J to just queue any new requests until the response has been received and only then send the newest request (discarding all those in the middle).


                          That sounds good to me, but will the a4j guys go for it?

                          • 10. Re: Conversation processing another request error when using
                            reind

                             

                            "cwash" wrote:
                            That sounds good to me, but will the a4j guys go for it?


                            Let's hope so:
                            https://ajax4jsf.dev.java.net/issues/show_bug.cgi?id=42