Uploaded image for project: 'Nuxeo Platform'
  1. Nuxeo Platform
  2. NXP-11677

Make JSF/Seam more resiliant to multithreaded navigation



    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.8
    • Component/s: Seam / JSF UI


      the problem

      People are more and more used to multi-tab, multi-window and ajax navigation.
      This creates issues with the JSF/Seam stack :

      • JSF maintain server side state for the views : only a limited number can be kept (currently 4)
      • Seam Session/Conversation scope are mono-threaded (i.e. synchronized via a lock)

      This problem is not specific to Nuxeo and exists since the beginning (this is the very nature of Seam/JSF) but it is more and more problematic :

      possible approaches

      The real definive solution would be to have a better state management system.
      Moving the state management logic on the client side (like when using an Html/JS framework like AngularJS) is the target solution.

      However, we should be able to find a solution for the current webapp framework.

      improving JSF/Seam stack

      We should be able to significantly improve the situation by working on the infrastructure building blocks.

      We have already done some significants improvements by better managing ajax requests (NXP-11136, NXP-11029).

      Next step could be to fork our current version of Seam to:

      • allow Views state mananagement to be done on a per conversation basis
        • manage n views per conversation (i.e. tab thanks to NXP-11331)
      • make conversation locking more efficient (granular) and more resilient
        • only lock during actual write access (focus on INVOKE_APPLICATION phase ?)
        • provide/log more in case of issue
        • issue an http redirect instead of a crash ?

      NB : In parallel we could also probably make default Nuxeo Seam Beans more stateless so that Injection issues are less a problem.


          Issue Links



              • Assignee:
                tdelprat Thierry Delprat
                tdelprat Thierry Delprat
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: