ICEfaces
  1. ICEfaces
  2. ICE-3578

PersistentFacesState.render guarding against re-entrancy

          Details

          • Type: Improvement Improvement
          • Status: Closed
          • Priority: Major Major
          • Resolution: Won't Fix
          • Affects Version/s: 1.7.1
          • Fix Version/s: 2.0-Alpha3, 2.0.0
          • Component/s: None
          • Labels:
            None
          • Environment:
            ICEfaces

            Description

            If PersistentFacesState.render() is called for the current PersistentFacesState, and attempt is made to render the current view being rendered. This should be detected and the method simply return.

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Ken Fyten added a comment -

              Commit caused all push operations to fail. Backed out. This needs to be revisited for 1.8.

              Show
              Ken Fyten added a comment - Commit caused all push operations to fail. Backed out. This needs to be revisited for 1.8.
              Hide
              Permalink
              Ken Fyten added a comment -

              Commit was backed out on the icefaces-1.7 branch (r17671).

              Show
              Ken Fyten added a comment - Commit was backed out on the icefaces-1.7 branch (r17671).
              Hide
              Permalink
              Ted Goddard added a comment -

              Mircea has an improved implementation of this fix:

              public void executeAndRender() throws RenderingException

              { if (!lifecycleLock.isHeldByCurrentThread()) return; acquireLifecycleLock(); execute(); render(); }

              However the renderLater() call is intended to resolve this explicitly. One complication of the earlier change for this feature is that an application-managed thread pool calling render() might have these calls rejected due to the Thread inheritance of the PersistentFacesState instance. The above implementation would likely resolve this, but it is more straightforward to request that applications switch to SessionRenderer, RenderManager, or the renderLater() call.

              Show
              Ted Goddard added a comment - Mircea has an improved implementation of this fix: public void executeAndRender() throws RenderingException { if (!lifecycleLock.isHeldByCurrentThread()) return; acquireLifecycleLock(); execute(); render(); } However the renderLater() call is intended to resolve this explicitly. One complication of the earlier change for this feature is that an application-managed thread pool calling render() might have these calls rejected due to the Thread inheritance of the PersistentFacesState instance. The above implementation would likely resolve this, but it is more straightforward to request that applications switch to SessionRenderer, RenderManager, or the renderLater() call.
              Hide
              Permalink
              Ted Goddard added a comment -

              Re-entrancy is a general problem for a push API , so this should be considered for 2.0 or 1.8DR3.

              Show
              Ted Goddard added a comment - Re-entrancy is a general problem for a push API , so this should be considered for 2.0 or 1.8DR3.
              Hide
              Permalink
              Ted Goddard added a comment -

              ICEfaces 2.0 uses client-initiated rendering driven by a server notification, so re-entrancy is not possible. It is likely not necessary to fix this in ICEfaces 1.8.x since a re-entrant condition is an application design problem and new application design should be taking place for ICEfaces 2.0.

              Show
              Ted Goddard added a comment - ICEfaces 2.0 uses client-initiated rendering driven by a server notification, so re-entrancy is not possible. It is likely not necessary to fix this in ICEfaces 1.8.x since a re-entrant condition is an application design problem and new application design should be taking place for ICEfaces 2.0.

                People

                • Assignee:
                  Ted Goddard
                  Reporter:
                  Ted Goddard
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: