2 Replies Latest reply on Sep 28, 2011 3:17 AM by Daniel Lechner

    Cannot find conversation when using a link during page-setup

    Daniel Lechner Novice


      I've an application running on JBoss AS 5.1.0.GA with Seam 2.2.2.Final.
      Most of the time, everything works fine ;)

      But if a user with a low bandwidth is using the webapp, there is a chance of being redirected to the no-conversation-view-id - even if a conversation is running:

      On (one of the) problematic page(s), there is a form containing a table containing some information and a h:commandLink in each table row. When entering this page, a new conversation is started.
      Usually the whole page is populated to the user immediately. But it may be possible that it takes some time until the page is fully loaded. The user sees the page building up row per row.
      If the user is fast enough and uses one of the command-links while only a part of the page is loaded, he will be redirected to the no-conversation-view-id.

      I guess the problem is the following: Even with javax.faces.STATE_SAVING_METHOD=server, JSF appends a hidden field javax.faces.ViewState in each form. This auto-generated identifier token, passed through the hidden form field, is used to identify the component tree object in the users server-side session.

      Since the page is not fully loaded (or displayed) by the browser, the POST-request is sent without the ViewState. I was able to verify this with wireshark: in the standard case the identifier token is part of the POSt while in the problematic case it is not.

      So the component-tree cannot be found, seam writes No stored conversation into the log-file (but no exception) and redirects to the no-conversation-view-id with the faces message The conversation ended, timed out or was processing another request.

      Is this a known issue or am I doing something wrong? Is it possible to move the hidden field containing the javax.faces.ViewState to the beginning of each form instead of the end?

      Btw: to handle concurrent requests there's a RichFaces queue and a defined concurrent-request-timeout in components.xml.