ICEfaces
  1. ICEfaces
  2. ICE-1773

Tomcat 6 asynchronous feature uses recycled events (IllegalStateException)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6
    • Fix Version/s: 1.7
    • Component/s: None
    • Labels:
      None
    • Environment:
      Tomcat 6, TomcatPushServlet

      Description


      The following exception is thrown occasionally:

      java.lang.IllegalStateException: The event object has been recycled and is no longer associated with a request
              at org.apache.catalina.connector.CometEventImpl.close(CometEventImpl.java:93)
              at com.icesoft.faces.webapp.http.servlet.EventResponder.run(TomcatPushServlet.java:143)
              at com.icesoft.faces.webapp.http.core.ViewQueue.put(ViewQueue.java:16)
              at com.icesoft.faces.webapp.http.servlet.ServletView$1.run(ServletView.java:54)
              at com.icesoft.faces.webapp.http.servlet.ServletView.broadcastTo(ServletView.java:131)
              at com.icesoft.faces.webapp.http.servlet.ServletView.put(ServletView.java:106)
              at com.icesoft.faces.context.PushModeSerializer.serialize(PushModeSerializer.java:57)
              at com.icesoft.faces.context.DOMResponseWriter.endDocument(DOMResponseWriter.java:176)
              at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:580)
              at com.icesoft.faces.application.D2DViewHandler.renderView(D2DViewHandler.java:154)
              at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107)
              at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:268)
              at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:137)
              at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.render(PersistentFacesState.java:146)
              at com.icesoft.faces.async.render.RunnableRender.run(RunnableRender.java:142)
              at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:643)
              at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:668)
              at java.lang.Thread.run(Thread.java:613)

        Issue Links

          Activity

          Ted Goddard created issue -
          Hide
          Ted Goddard added a comment -

          Exception may be harmless, but we should ensure that it is not regularly printed in the log.

          Show
          Ted Goddard added a comment - Exception may be harmless, but we should ensure that it is not regularly printed in the log.
          Ted Goddard made changes -
          Field Original Value New Value
          Assignee Jack van Ooststroom [ jack.van.ooststroom ]
          Hide
          Ted Goddard added a comment -

          For 1.7, a sufficient fix may be to reduce the reporting of the exception. For 1.7.1, the full root cause of the exception should be fixed.

          Show
          Ted Goddard added a comment - For 1.7, a sufficient fix may be to reduce the reporting of the exception. For 1.7.1, the full root cause of the exception should be fixed.
          Ted Goddard made changes -
          Fix Version/s 1.7 [ 10080 ]
          Jack Van Ooststroom made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #16073 Wed Mar 19 17:36:41 MDT 2008 jack.van.ooststroom Fixed JIRA ICE-1773 : Tomcat 6 asynchronous feature uses recycled events (IllegalStateException)
          Files Changed
          Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/TomcatPushServlet.java
          Hide
          Jack Van Ooststroom added a comment -

          I could easily reproduce this using AuctionMonitor and an Internet browser with two tabs/windows pointing to it. Basically what seemed to happen with multiple views open is the following sequence of events:

          • request comes in, an EventResponder is created and added to the ViewQueue
          • one view completes its render and notifies the EventResponder through the ViewQueue
          • the EventResponder picks up the updates and sends them using a response
          • the other view completes its render and notifies the EventResponder through the ViewQueue
          • as there is no "request ready" the IllegalStateException is thrown

          I refactored the TomcatPushServlet to basically have the AHS-like capability:

          • request comes in, an EventResponder is created for the session if not already done so, the EventResponder's new sendResponse(...) method is invoked which checks to see if there are updates ready: if so they are send back right away, if not the request is set as the pending request (thread is released)
          • an update is added to the ViewQueue and the EventResponder is notified which first checks to see if there is a pendingRequest: if so the updates are send back right away, if not nothing happens (thread is released)

          This way there is always one EventResponder per session and both treads are able to push updates back to the client: the thread handling the request and the thread handling the updates.

          Show
          Jack Van Ooststroom added a comment - I could easily reproduce this using AuctionMonitor and an Internet browser with two tabs/windows pointing to it. Basically what seemed to happen with multiple views open is the following sequence of events: request comes in, an EventResponder is created and added to the ViewQueue one view completes its render and notifies the EventResponder through the ViewQueue the EventResponder picks up the updates and sends them using a response the other view completes its render and notifies the EventResponder through the ViewQueue as there is no "request ready" the IllegalStateException is thrown I refactored the TomcatPushServlet to basically have the AHS-like capability: request comes in, an EventResponder is created for the session if not already done so, the EventResponder's new sendResponse(...) method is invoked which checks to see if there are updates ready: if so they are send back right away, if not the request is set as the pending request (thread is released) an update is added to the ViewQueue and the EventResponder is notified which first checks to see if there is a pendingRequest: if so the updates are send back right away, if not nothing happens (thread is released) This way there is always one EventResponder per session and both treads are able to push updates back to the client: the thread handling the request and the thread handling the updates.
          Hide
          Jack Van Ooststroom added a comment -

          Marking this one as FIXED.

          Show
          Jack Van Ooststroom added a comment - Marking this one as FIXED.
          Jack Van Ooststroom made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Jack Van Ooststroom made changes -
          Link This issue blocks ICE-2845 [ ICE-2845 ]
          Jack Van Ooststroom made changes -
          Link This issue blocks ICE-2944 [ ICE-2944 ]
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Assignee Jack van Ooststroom [ jack.van.ooststroom ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved: