14 Replies Latest reply on Dec 30, 2008 10:46 AM by marx3

    FINALLY, the ajax-bug is replicated in seam-booking

    Kristoffer T Newbie

      I now post a followup to the bug that has been around in our system for ages, since day one really.
      It arises as a


      
      cannot read xxxx on javassist yyyyyyy
      
      



      every time a ajax request is triggered multiple times.
      It seems that it is some sort of race-condition or that seam does not create the components fast enough. It occurs more often on a slow
      development laptop than in production environments, where the response time is way faster.


      HOW TO REPLICATE:


      Rewrite the find-method in the HotelSearchAction-class, in the seam booking example application.
      It should look like this.


      
      public void find() {
              page = 0;
              queryHotels();
              try {
                  Thread.sleep(1000 * 5);
              } catch (InterruptedException ignore) {
              }
          }
      
      



      Now, start the application, register a user and enter main.html.
      Click multiple times on the search hotel button. Depending upon how fast your computer is, you might need to do more than a double-click.
      Sometimes you may need to klick fast up to 5-8 times. But it will occur.



      You will end up with an exception that says:


      
      Caused by javax.servlet.ServletException with message: javax.el.ELException: /main.xhtml @74,130 rendered=#{hotelSearch.nextPageAvailable}: Error reading nextPageAvailable on type org.javassist.tmp.java.lang.Object_$$_javassist_4
      
      



      Which in turn comes from a synchronization problem.


      
      Caused by org.jboss.seam.core.LockTimeoutException with message: could not acquire lock on @Synchronized component: hotelSearch
      
      



      This is in a way funny, since the hotelSearch-component is not annotated with synchronized.
      Anyway, our application does not throw an exception like this, but we to have tried synchronizing our involved components, with no luck.
      Our exception is mostly this


      
      Caused by javax.servlet.ServletException with message: javax.el.ELException: /layout/template.xhtml @18,59 rendered=#{authenticator.inSpecialMode}: Error reading inSpecialMode on type se.session.Authenticator_$$_javassist_4
      
      



      Which in turn comes from the failed injections


      
      Caused by org.jboss.seam.RequiredException with message: @In attribute requires non-null value: authenticator.entityManager 
      
      



      This problem occurs all over the application, always when an ajax request is double-clicked and seam tries to recreate seam components and runs out of time.
      In 99% of the case it is the first read property of our authenticator-component that fails, and most often it is that seam cannot create a entityManager to inject, and the system fails due to that the annotation is set to only inject, without create.
      Removing the entityManager from the component will only result in that seam cannot inject another component instead, until you have no injections left in authenticator, and it still fails!


      For us, this is a big problem, since all ajax parts of the application is extremely fragile and fails as soon as a double-click is made.
      This in turn has stolen a lot of time for us, since we need to script our way to disabling buttons and most of the time remove tha ajax-functionality all together, just to get a 100% stable and reliant system.


      At the moment there are more pressing bugs for us, like the asynchronous mailing, and quartz integrations that does not work properly, but next to that, we would be very happy if you could hunt down this bug.
      It has been around for ages, I promise :)


      These problems concern all versions of seam that we have tested, and they exist in trunk today (081216)


      /K

        • 1. Re: FINALLY, the ajax-bug is replicated in seam-booking
          Luke Simon Newbie

          Richfaces uses Prototype in a very badly way!
          how many empty

          <script></script>

          do you have in your pages?
          The cause that this bug is unfixed for ages IMHO, it's the proof that nobody use it for real projects.

          • 2. Re: FINALLY, the ajax-bug is replicated in seam-booking
            Kristoffer T Newbie

            Just the standard richfaces/seam inclusion of scripts.
            They are broken into separate lines here, for clarity.
            The empty script-includes you refer to has shown up some time for us as well, wich forced us to manually include jquery for our scripts
            to work. This behaviour seems to have disappeared again though, and this hack-of-a-solution is now removed from our system.
            Our current included java scripts:


            <link class='component' rel='stylesheet' type='text/css' href='/a4j/s/3_2_2.SR1org/richfaces/renderkit/html/css/basic_classes.xcss/DATB/eAFrvajdHLp8hjQAEgwDtA__' />
            <link class='component' rel='stylesheet' type='text/css' href='/a4j/s/3_2_2.SR1org/richfaces/renderkit/html/css/extended_classes.xcss/DATB/eAFrvajdHLp8hjQAEgwDtA__' media='rich-extended-skinning' />
            <script type='text/javascript' src='/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/jquery/jquery.js'></script>
            <script type='text/javascript' src='/a4j/g/3_2_2.SR1org.ajax4jsf.javascript.PrototypeScript'></script>
            <script type='text/javascript' src='/a4j/g/3_2_2.SR1org.ajax4jsf.javascript.AjaxScript'></script>
            <script type='text/javascript' src='/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/available.js'></script>
            <script type='text/javascript' src='/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/script/controlUtils.js'></script>
            <script type='text/javascript' src='/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/utils.js'></script>
            <script type='text/javascript' src='/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/browser_info.js'></script>
            <script type='text/javascript' src='/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/modalPanel.js'></script>
            <script type='text/javascript' src='/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/modalPanelBorders.js'></script>
            <link class='component' rel='stylesheet' type='text/css' href='/a4j/s/3_2_2.SR1org/richfaces/renderkit/html/css/modalPanel.xcss/DATB/eAFrvajdHLp8hjQAEgwDtA__' />
            <script type='text/javascript'>window.RICH_FACES_EXTENDED_SKINNING_ON=true;</script>
            <script type='text/javascript' src='/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/skinning.js'>
            </script>
            <meta http-equiv="Content-Type" content="text/html" />
            
            


            • 3. Re: FINALLY, the ajax-bug is replicated in seam-booking
              Luke Simon Newbie

              Another proof is that NOBODY reply to this post :) that's is a really common problem that happens to me very often too.

              • 4. Re: FINALLY, the ajax-bug is replicated in seam-booking
                Samuel Mendenhall Apprentice

                I would expect, if you exceed the concurrent request time on a Synchronized object for the could not acquire lock on @Synchronized component to be thrown, this is expected behavior.


                Two ways to handle this situation, and it is more common than you think.  See http://www.jboss.org/file-access/default/members/jbossrichfaces/freezone/docs/devguide/en/html_single/index.html#QueueandTrafficFloodProtection  for the Richfaces side of things.  You should add eventsQueue, requestDelay, and ignoreDupResponses to each ajax/richfaces component.


                And, I've seen many times in production environments the default concurrent-request-timeout="500" to be too small.  Increase it to 2000 and try again.

                • 5. Re: FINALLY, the ajax-bug is replicated in seam-booking
                  Francisco Jose Peredo Noguez Master

                  I think you should create an account in Seam JIRA, and create a new issue of type bug explaining this problem, if you can post a patch file of your changes to seam-booking in the bug issue, that would be even better.



                  I think you should do the same thing about the bad practices you have noticed for RichFaces.



                  Regards,

                  • 6. Re: FINALLY, the ajax-bug is replicated in seam-booking
                    judy guglielmin Novice

                    IMHO, this is not a Seam bug.  This is a responsibility of the ajax framework you choose, is it not?  For example, this is not a problem with ICEfaces as the ajax bridge takes care of this for developers.  Unless you strictly use seam-remoting and your own ajax handling, then perhaps maybe a Seam jira?  Otherwise, it might be more prudent to raise a jira/bug for whatever ajax framework you are using.

                    • 7. Re: FINALLY, the ajax-bug is replicated in seam-booking
                      Francisco Jose Peredo Noguez Master

                      judy guglielmin wrote on Dec 17, 2008 18:35:


                      IMHO, this is not a Seam bug.  This is a responsibility of the ajax framework you choose, is it not?  For example, this is not a problem with ICEfaces as the ajax bridge takes care of this for developers.


                      So you mean you tested this in the booking example built with icefaces in jboss-seam-2.1.0.SP1\examples\icefaces\ an it does not crash?


                      Unless you strictly use seam-remoting and your own ajax handling, then perhaps maybe a Seam jira?



                      Well, if the seam-booking example crashes, then, it is a bug in the Seam distribution... isn't it? the exception is: Caused by org.jboss.seam.core.LockTimeoutException with message: could not acquire lock on @Synchronized component: hotelSearch that seems like a Seam problem to me...


                      Otherwise, it might be more prudent to raise a jira/bug for whatever ajax framework you are using.



                      AFAIK seam-booking uses RichFaces for that... the find-method in the HotelSearchAction-class is called like this:

                      <a:commandButton id="findHotels" value="Find Hotels" action="#{hotelSearch.find}" reRender="searchResults"/>
                      







                      • 8. Re: FINALLY, the ajax-bug is replicated in seam-booking
                        Stuart Douglas Master

                        This is a seam bug, but only to the extent that the a4j:commandButton in the example should have an eventQueue. As it clearly states in the docs, access to conversation scoped beans are serialized. If this was not the case you would have way more weird threading bugs and the framework would be basically unusable.


                        • 9. Re: FINALLY, the ajax-bug is replicated in seam-booking
                          Ingo Jobling Master

                          Luke Simon wrote on Dec 16, 2008 14:43:


                          Richfaces uses Prototype in a very badly way!
                          how many empty
                          <script></script>

                          do you have in your pages?
                          The cause that this bug is unfixed for ages IMHO, it's the proof that nobody use it for real projects.


                          Just out of curiosity I checked, we have no empty <script></script> in our pages.


                          On what you are basing your statement that nobody use it for real projects?  We are using Seam with Richfaces for a real project, and are very satisfied with the results. 


                          • 10. Re: FINALLY, the ajax-bug is replicated in seam-booking
                            Kristoffer T Newbie

                            Thanks for all inputs and acknoledgements.
                            I did not try the eventsQueue, requestDelay and concurrent-request-timeout settings. The other settings however have been tested. That beeing ajaxSingle and ignoreDupResponses.
                            The behaviour is consistent with all a4j:commandXXXXX. Dropdowns, buttons and commandLinks.
                            Thus, the behaviour is not bound to any specific typ of taglib/tag but to the server-side handling of the asynchronous requests.
                            A jira has been filed, and put under unscheduled. It has position 401...thus, this might take a while :P


                            /K

                            • 11. Re: FINALLY, the ajax-bug is replicated in seam-booking
                              Kristoffer T Newbie

                              Kristoffer Teuber wrote on Dec 18, 2008 18:44:


                              Thanks for all inputs and acknoledgements.
                              I did not try the eventsQueue, requestDelay and concurrent-request-timeout settings. The other settings however have been tested. That beeing ajaxSingle and ignoreDupResponses.
                              The behaviour is consistent with all a4j:commandXXXXX. Dropdowns, buttons and commandLinks.
                              Thus, the behaviour is not bound to any specific typ of taglib/tag but to the server-side handling of the asynchronous requests.
                              A jira has been filed, and put under unscheduled. It has position 401...thus, this might take a while :P

                              /K


                              ...and now I have tried those settings as well...sorry to say, the results are the same.
                              You can still bombard the server with request and seam will fail.


                              /K

                              • 12. Re: FINALLY, the ajax-bug is replicated in seam-booking
                                Luke Simon Newbie

                                Ingo Jobling wrote on Dec 18, 2008 06:01:



                                Luke Simon wrote on Dec 16, 2008 14:43:


                                Richfaces uses Prototype in a very badly way!
                                how many empty
                                <script></script>

                                do you have in your pages?
                                The cause that this bug is unfixed for ages IMHO, it's the proof that nobody use it for real projects.


                                Just out of curiosity I checked, we have no empty <script></script> in our pages.

                                On what you are basing your statement that nobody use it for real projects?  We are using Seam with Richfaces for a real project, and are very satisfied with the results. 



                                Lucky you if you're happy! Me...no! :-D
                                Find something on the web that speak about Seam, without count the Hello world with Seam.
                                On this forum there are maximum 30 users, 80 users in the Facebook group, nothing elsewhere.


                                Search other web framework on google...and you will see, try with Symphony, Django, Rails..


                                oh...wait, they're not enterprise :-)

                                • 13. Re: FINALLY, the ajax-bug is replicated in seam-booking
                                  judy guglielmin Novice

                                  So you mean you tested this in the booking example built with icefaces ... an it does not crash?

                                  The icefaces example is tested using selenium scripts at very quick speeds and double clicking on the components (with partialSubmit="true" which ajax-enables the input components), causes no problems.



                                  @Francisco Peredo
                                  You are absolutely correct that this issue pertains to Seam and to Richfaces (in particular the seam-booking example), but since many of the examples are the hotel booking application, I guess I just wanted to draw attention to the fact that not all the booking examples exhibited this problem and to clear any concerns of ICEfaces users that might be reading this posting. Since Seam can be used without ajax at all, it seemed logical (to me at least) that the chosen implementation of ajax should maintain this synchronization (@Samuel Mendenhall had several suggestions for Richfaces users).  Then as well, seam-remoting should ensure that  this is done, etc. 


                                  • 14. Re: FINALLY, the ajax-bug is replicated in seam-booking
                                    marx3 Apprentice

                                    -could not acquire lock on @Synchronized component- is an error in our applications too. New RF 3.3.0 (CR1 for now) has possibility to define global queue - we wil try it, because we too have big problems with concurrent ajax request. Properly defined queue (the same for every ajax component) help to some degree, but it's very annoying to define it on every single component and it's easy to miss some components.
                                    We heavily use nested conversation and conversation stack and we had to make every button single-clickable, because double click on button executing nested conversation always caused an error: org.jboss.seam.NoConversation