[ 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
