2 Replies Latest reply on May 6, 2014 8:34 AM by Tomas Remes

    JSF navigation in postconstruct creates a 100% CPU extra thread

    Akaine Harga Novice

      Hi everyone,

       

      I've detected a strange issue recently. Let's consider the following code inside a managed bean:

      @ManagedBean
      @ViewScoped
      public class RecordUI implements Serializable{
          ...   
      
          @PostConstruct
          public void initializeView(){
              if(FacesContext.getCurrentInstance().getExternalContext().getFlash().get("someRecordIdParameter")==null){
                  FacesContext.getCurrentInstance().getApplication().getNavigationHandler().handleNavigation(FacesContext.getCurrentInstance(), null, "/pages/someRecordsManagerPage.faces?faces-redirect=true");
              }else{
                  ...
              }
          }
      
      

       

      The idea is to check every time I load a record specific page if the record id parameter is being sent in the flash context, and if not - then redirect user to some records manager page.

       

      So the steps to reproduce the issue are:

      1. Load the page sending the parameter in the flash.

      2. Hit F5 to reload the page. At this moment you should be redirected to the page specified in the navigation handler method.

      3. Now if you check the OS's process monitor it should have WildFly's java process consuming one of CPUs by 100%.

       

      The issue is accumulative, I can repeat the process to eat up all of the CPUs.

       

      I could avoid the issue by moving the parameter check and redirection rule to a phase listener but:

      1. It would require a pretty custom rules (and I have a lot of pages with similar logic).

      2. I'd really would like to understand why this is happening to be able to overcome this problem using a more elegant approach than the one involving page rules inside a phase listener if it can be avoided at all.

       

      Any ideas?

       

      Thanks and Regards