Setting Conversation Timeout dynamically via setTimeout() doesnt work properly

[arin.arin.venarc.com]

Referring to the documentation on setting conversation timeouts, there are two obvious ways of setting the timeout.

The first is in the components configuration:

<core:manager concurrent-request-timeout="500" 
conversation-timeout="600000" 
conversation-id-parameter="cid"/>

And if we want to set it for a specific page, we can use the page configuration:

<page view-id="/page.xhtml" timeout="120000"/>

This will override the conversation timeout for that page. There is a third way to set the background conversation timeout dynamically as described on page 300 of Seam in Action is to call the setTimeout() method in the built-in conversation component.

Conversation.instance().setTimeout(Integer.valueOf((720000));

This works and sets the timeout for the conversation dynamically in the action, but I believe there is a bug in the prepareBackswitch() function in the FacesManager class that resets the conversation timeout back to whatever the timeout is set in the pages configuration and if no timeout is set there, defaults back to the timeout set in the components configuration. This renders the setTimeout() function useless.

public void prepareBackswitch(FacesContext facesContext) 
   {
      Conversation conversation = Conversation.instance();

      //stuff from jPDL takes precedence
      org.jboss.seam.pageflow.Page page = 
            Manager.instance().isLongRunningConversation() &&
            Init.instance().isJbpmInstalled() && 
            Pageflow.instance().isInProcess() && Pageflow.instance().isStarted() ?
                  Pageflow.instance().getPage() : null;
      
      if (page==null)
      {
         //handle stuff defined in pages.xml
         Pages pages = Pages.instance();
         if (pages!=null) //for tests
         {
            String viewId = Pages.getViewId(facesContext);
            org.jboss.seam.navigation.Page pageEntry = pages.getPage(viewId);
            if ( pageEntry.isSwitchEnabled() )
            {
               conversation.setViewId(viewId);
            }
            if ( pageEntry.hasDescription() )
            {
               conversation.setDescription( pageEntry.renderDescription() );
            }
            else if(pages.hasDescription(viewId))
            {
               conversation.setDescription( pages.renderDescription(viewId) );  
            }
            conversation.setTimeout( pages.getTimeout(viewId) );
            conversation.setConcurrentRequestTimeout( pages.getConcurrentRequestTimeout(viewId) );
         }
      }
      else
      {
         //use stuff from the pageflow definition
         if ( page.isSwitchEnabled() )
         {
            conversation.setViewId( Pageflow.instance().getPageViewId() );
         }
         if ( page.hasDescription() )
         {
            conversation.setDescription( page.getDescription() );
         }
         conversation.setTimeout( page.getTimeout() );
      }
      flushConversationMetadata();
   }

Referring also to the reference on the conversation, the function setTimeout() should work in setting the timeout dynamically.

Conversation API

I think being forced to use the pages configuration for setting a timeout for a specific page is not very intuitive and there should be a way to set the timeout from the conversation component without having it be overwritten by the page timeout or the components configuration. I am not sure if I am doing something wrong in the way I am using the setTimeout() function but I think prepareBackswitch should check to see if the timeout has already been set before trying to set the conversation timeout from the pages configuration.

[asookazian]

I have not tried what you are doing, but I will comment that there should be a conversation-timeout or simply timeout attriubte for the @Begin annotation.

In any event, it seems that perhaps you have stumbled upon a bug if your programmatic setting via Conversation API for timeout is being overridden...

Also, what is your use case that requires this functionality to begin with?  It seems to me that page level timeout should be good enough (i.e. supply enough fine-grained control) in most cases (and I've never even used that!)