9 Replies Latest reply on Jun 10, 2009 10:27 AM by jan1972

    ConcurrentRequestTimeoutException when double-clicking in jBPM

    jan1972 Newbie
      Hi,

      I believe I have found a bug in Seam with conversational jBPM: if a page takes too long to display and the user is a "nervous clicker", he will experience a ConcurrentRequestTimeoutException thrown in thrown in org.jboss.seam.core.Manager.restoreAndLockConversation

      Environment: Seam 2.1.2.GA / JBoss AS 5.0.1.GA

      How to reproduce using the '/seam-numberguess' example provided in the release.

      1. Modify the following method in org.jboss.seam.example.numberguess.NumberGuess to be:

         public int getRemainingGuesses() {
              System.out.println( "Waiting for " + sec + " seconds..." );
              try
              {
                  Thread.sleep( sec * 1000 );
              }
              catch ( InterruptedException e )
              {
              }
              System.out.println( "... done!" );
              return maxGuesses-guessCount;
          }
      2. Build and deploy the example to JBoss AS 5.0.1.GA
      3. Browse to http://localhost:8080/seam-numberguess
      ==> Observe that the server stdout shows that it's waiting for 10 seconds
      4. When the page finally shows, enter 50 and press 'Guess'
      ==> Observe that the server stdout shows again that it's waiting for 10 seconds
      5. During those 10 seconds, click again on the 'Guess' button

      ==> watch the nice crash & the associated HTTP Error 500


      Of course, this simplistic example can be avoided by not adding these 10 seconds but these were only added to help reproduce the issue.

      May I submit a bug?

      Thanks in advance
      Jan
        • 1. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
          Leo van den berg Master

          Jan,


          I don't think it's a bug. Sleeping a thread in this was is a very no-do in web applications. I think its cashing on trying to accces the locked properties of the class.


          Leo

          • 2. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
            Yasser Hawari Newbie

            i am working on an application that has a few functions which do take a long time to finish. if the user clicks on the button twice he will definitely get this . Seam guy know this, so they advice u to use @Asynchronous with poll functionality of richfaces. there are other ways to deal with this if richfaces is ur UI. have a look at seam's guide section 7.11

            • 3. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
              jan1972 Newbie

              Leo:
              I am not sure I understand what you mean... Actually I called it a crash, but it's an uncaught exception raised by Seam because the conversation Manager fails to acquire the ConversationEntry lock.
              If ce.lock() returns false, there is an explicit:


                       throw new ConcurrentRequestTimeoutException(Concurrent call to conversation);


              So, admittedly that Thread.sleep() is not a good idea, it might be something else taking some time: database hit, computations, even another process.
              To tell you the truth, by fast clicking, I managed some times to reproduce it without the Thread.sleep(), but you gotta be patient/lucky, which is why I added the sleep.


              Yasser:
              Thanks for the tip. @Asynchronous is something we already use in several places. The issue is that this time, we are developing an interface which needs to be accessed from a cell phone (and not only smart phones, also the pretty old/basic ones) and therefore, we cannot do JavaScript to poll for anything.



              • 4. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
                marx3 Apprentice

                The only working method is to completely block UI after button/link click. I do that via onClick method showing modal div please wait on top of a page. When request is completed, page reloads (without div).

                • 5. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
                  Leo van den berg Master

                  Jan,



                  Fast clicking can be helped completely by adding a Queue to your pages. Adding ajax buttons which reference that queue can help you eliminate this behaviour.


                  It needs some tuning, but it works perfectly. It basically helps you wait for a response until the previous one has finished.


                  Be aware that web-technology is NOT perfect, but luckily JBoss also provide help for you client side. Loot at the Ajax4JSf documentation.


                  Success,


                  Leo


                  P.S. Be more positive, I think the Seam guys have done a great job, and don't blame them for the problems in HTTP!


                  • 6. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
                    jan1972 Newbie
                    This UI freezing is a good solution when you allow yourself usage of JavaScript. As explained earlier, we do not (in that very particular case).

                    What surprises me is that such a double-click issue apparently already existed in regular JSF pages in early versions of Seam... and now it seems that I just unveiled a similar issue in the pageflow. See: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3979681

                    Also, in Seam 2.0.2.SP1 which we used so far, this used to work, apparently because the conversation ID was not always properly propagated, which seems to have been fixed in 2.1.1.GA
                    • 7. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
                      jan1972 Newbie

                      Sorry Leo, I had not yet seen your answer. As said in that case, I have no choice to use any JavaScript unfortunately (basic cell phone application).


                      Anyway, thanks for your answers.
                      From these, I conclude that this is neither a bug nor something I have a workaround for.
                      So all I can do is dropping Seam/jBPM and using a not concurrency-locked model (and manage the locks by hand in my own code). Is that correct?



                      Leo van den Berg wrote on Jun 10, 2009 09:42:


                      P.S. Be more positive, I think the Seam guys have done a great job, and don't blame them for the problems in HTTP!


                      Did I give the impression to blame anybody? or even to be negative??? Reading again my posts, I have always been rather factual. If not, this is something for which I apologize.

                      • 8. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
                        Leo van den berg Master

                        Sorry for that, was not my intention,


                        but this discussion is more about the problems we all encounter in  using WEB cleinst, the client want's it, but I am still puzzled how it is possible that we still need to create more-aand-more framework which abstract away all those problem instead of solving the problem at its source; the limitations of HTTP.


                        Your first email starts with : I believe I have found a bug and ends with May I submit a bug? while you described a web / HTTP-problem,


                        Sorry for my my rudeness, I apologize for that,


                        Leo






                        • 9. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
                          jan1972 Newbie

                          No problem.


                          I am being factual and am still personally convinced that this is a bug in the conversation management in Seam. Or let's phrase it another way if you wish: Seam's promise to provide conversation management causes more problems than it solves in this very particular case.


                          This is why I was using this bug phrasing. Also bugs are in the very nature of software, so I don't see nailing one down as being negative, in the contrary.


                          Cheers

                          Jan