[jira] Created: (BEEHIVE-1100) page flow shared by two threads can be destroyed by one but isn't reinitialized by the other

[Beehive - Dev mailing list]

page flow shared by two threads can be destroyed by one but isn't reinitialized by the other
--------------------------------------------------------------------------------------------

         Key: BEEHIVE-1100
         URL: http://issues.apache.org/jira/browse/BEEHIVE-1100
     Project: Beehive
        Type: Bug

  Components: NetUI  
    Versions: V1, 1.0.1, v.next    
    Reporter: Eddie O'Neil
 Assigned to: Eddie O'Neil
     Fix For: v.next


This is a JPF threading issue where two threads can start off sharing the same Page Flow.  When one thread destroys that JPF, the second thread continues to reuse the destroyed instance.  This can cause problems when re-running the destroyed JPF because any Controls or other fields cleared in the "onDestroy" lifecycle handler can cause unexpected exceptions / behavior.  For example:

Thread 1:  current page flow is /a/A.jpf
1: reference /a/A.jpf
2: execute action "step 2"
5: attempt to execute action "step 3" -- strange behavior because
internal state has been whacked by "destroy".

Thread 2: current page flow is /a/A.jpf
3: reference /a/A.jpf
4: forward to /b/B.jpf -- causes onDestroy to be called on A.jpf

I believe that the fix is to have the Thread1 re-create the JPF mid-request.  This means that Thread1 will lose the state /a/A.jpf, but in the current architecture, that makes sense because the JPF was destroyed.  When the JPF is re-created, it will attempt to run action "step2" which could work but might also fail with an error or redirect to the beginning of a wizard (for example).  Fortunately, this scenario is the same as the case where the user types this into their browser window:

  http://localhost:8080/fooWeb/somewizard/step2.do

and the action either works or fails.  It's just like starting a JPF over again in the middle of the request.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Beehive - Dev mailing list]

     [ http://issues.apache.org/jira/browse/BEEHIVE-1100?page=all ]

Eddie O'Neil updated BEEHIVE-1100:
----------------------------------

    Fix Version:     (was: v.next)
      Assign To:     (was: Eddie O'Neil)

In looking at this a bit more, it doesn't seem like a common scenario (no one else has reported it), and I can only make it happen in contrived situations with several threads pounding on the same HttpSession.  

I'm going to defer this till a subsequent release, but if anyone else runs into this problem, feel free to ask for a fix...

> page flow shared by two threads can be destroyed by one but isn't reinitialized by the other
> --------------------------------------------------------------------------------------------
>
>          Key: BEEHIVE-1100
>          URL: http://issues.apache.org/jira/browse/BEEHIVE-1100
>      Project: Beehive
>         Type: Bug

>   Components: NetUI
>     Versions: V1, 1.0.1, v.next
>     Reporter: Eddie O'Neil

>
> This is a JPF threading issue where two threads can start off sharing the same Page Flow.  When one thread destroys that JPF, the second thread continues to reuse the destroyed instance.  This can cause problems when re-running the destroyed JPF because any Controls or other fields cleared in the "onDestroy" lifecycle handler can cause unexpected exceptions / behavior.  For example:
> Thread 1:  current page flow is /a/A.jpf
> 1: reference /a/A.jpf
> 2: execute action "step 2"
> 5: attempt to execute action "step 3" -- strange behavior because
> internal state has been whacked by "destroy".
> Thread 2: current page flow is /a/A.jpf
> 3: reference /a/A.jpf
> 4: forward to /b/B.jpf -- causes onDestroy to be called on A.jpf
> I believe that the fix is to have the Thread1 re-create the JPF mid-request.  This means that Thread1 will lose the state /a/A.jpf, but in the current architecture, that makes sense because the JPF was destroyed.  When the JPF is re-created, it will attempt to run action "step2" which could work but might also fail with an error or redirect to the beginning of a wizard (for example).  Fortunately, this scenario is the same as the case where the user types this into their browser window:
>   http://localhost:8080/fooWeb/somewizard/step2.do
> and the action either works or fails.  It's just like starting a JPF over again in the middle of the request.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

    [ https://issues.apache.org/jira/browse/BEEHIVE-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589998#action_12589998 ]

Dominique Gallot commented on BEEHIVE-1100:
-------------------------------------------

I ran into this issue as well.
It is a common issue, if you have page that take some time to load before sending the data to the client.
Example
  we have Two controller Upload and List
  We go to Upload
  Then go to List Page ( this distroy the current Upload controller, but does not change the current ), this take time, page Upload is still show.
  So the user, which does not like to wait, click on a button page page upload, the PageFlowRequestProcessor.getFlowController is called, a current Upload Flow controller is already set, so it is reused.  
  But since it is destroyed all beehive control are null -> NPE.

The solution ( or workaround ? ) is to replace the lines ( PageFlowRequestProcessor:598 in the method getFlowController( RequestContext requestContext, String fcClassName )  )

            PageFlowController current = PageFlowUtils.getCurrentPageFlow( request, getServletContext() );
            if ( current != null && current.getClass().equals( fcClass ))
            {
by
            PageFlowController current = PageFlowUtils.getCurrentPageFlow( request, getServletContext() );
            if ( current != null && current.getClass().equals( fcClass ) && (!current.isDestroyed()))
            {

which does not reuse a current flow controller if it has already be destroyed.

Hope this can be usefull.
Dominique
 

> page flow shared by two threads can be destroyed by one but isn't reinitialized by the other
> --------------------------------------------------------------------------------------------
>
>                 Key: BEEHIVE-1100
>                 URL: https://issues.apache.org/jira/browse/BEEHIVE-1100
>             Project: Beehive
>          Issue Type: Bug
>          Components: NetUI
>    Affects Versions: 1.0, 1.0.1, 1.0.2
>            Reporter: Eddie O'Neil
>
> This is a JPF threading issue where two threads can start off sharing the same Page Flow.  When one thread destroys that JPF, the second thread continues to reuse the destroyed instance.  This can cause problems when re-running the destroyed JPF because any Controls or other fields cleared in the "onDestroy" lifecycle handler can cause unexpected exceptions / behavior.  For example:
> Thread 1:  current page flow is /a/A.jpf
> 1: reference /a/A.jpf
> 2: execute action "step 2"
> 5: attempt to execute action "step 3" -- strange behavior because
> internal state has been whacked by "destroy".
> Thread 2: current page flow is /a/A.jpf
> 3: reference /a/A.jpf
> 4: forward to /b/B.jpf -- causes onDestroy to be called on A.jpf
> I believe that the fix is to have the Thread1 re-create the JPF mid-request.  This means that Thread1 will lose the state /a/A.jpf, but in the current architecture, that makes sense because the JPF was destroyed.  When the JPF is re-created, it will attempt to run action "step2" which could work but might also fail with an error or redirect to the beginning of a wizard (for example).  Fortunately, this scenario is the same as the case where the user types this into their browser window:
>   http://localhost:8080/fooWeb/somewizard/step2.do
> and the action either works or fails.  It's just like starting a JPF over again in the middle of the request.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.