3 Replies Latest reply on Aug 30, 2009 7:17 PM by nbelaevski

    Best way to avoid RF-7248 ?

    joachimhb Aug 30, 2009 3:12 PM

      Hello,

      According to Issue 7248 https://jira.jboss.org/jira/browse/RF-7248 an infinite loop can occur inside RichFaces if a component instance is processed by concurrent requests.

      What is the best method for avoiding this issue ? I am pretty sure we are hitting this issue, which concequently leads to the CPU being used at 100%, which occurs, on average, within a day of a restart of the application. The server is running OK with one of these, but as the number of infinite loops increase, it effectively smothers the server with processing.

      One theory is to ensure that any one user can only execute one task at a time (through a custom filter that ensures that the filterChain.doFilter(request, response) is syncronized), I fear that this might lead to other unintentional bugs in the system (like one backend stall causing the user to actually have to close each and every browser window and login again - as even logout will be blocked by this measure).

      Does anyone have a good work around for this issue ?

      • 2112 Views
      • Tags:
        • 1. Re: Best way to avoid RF-7248 ?
          nbelaevski
          nbelaevski Aug 30, 2009 5:05 PM (in response to joachimhb)

          Hi,

          Can you please check if session-scoped component binding is used in your application?

            • Actions
          • 2. Re: Best way to avoid RF-7248 ?
            joachimhb Aug 30, 2009 5:52 PM (in response to joachimhb)

             

            "nbelaevski" wrote:
            Hi,

            Can you please check if session-scoped component binding is used in your application?


            Hello and thank you for your answer:

            There are some binding to session scoped MBeans, like:

            rich:tabPanel binding="#{ordreSummerMBean.tabPanel}"

            But usually we have used this with the rich:datascroller component, to be able to programatically pick the page that the datascroller shows (for instance upon a new search, or via the HOME and END buttons).

            I don't see how this can be implemented if the component werent bound to a session mbean though...

              • Actions
            • 3. Re: Best way to avoid RF-7248 ?
              nbelaevski
              nbelaevski Aug 30, 2009 7:17 PM (in response to joachimhb)

              Hi,

              Here is a quote from JSF spec.:

              Component bindings are often used in conjunction with JavaBeans that are dynamically
              instantiated via the Managed Bean Creation facility (see Section 5.8.1 "VariableResolver and
              the Default VariableResolver"). It is strongly recommend that application developers place
              managed beans that are pointed at by component binding expressions in "request"� scope.
              This is because placing it in session or application scope would require thread-safety, since
              UIComponent instances depends on running inside of a single thread.


              Another reason why components shouldn't be bound to session-scoped beans is that they are not serializable.

              In most cases it is possible to create separate request-scoped bean or design application code so, that binding wouldn't be necessary. Talking about rich:datascroller - there's "page" attribute that allows to define programmatically the page being displayed.

                • Actions