|
Chad Schoettger made changes - 13/Dec/05 05:33 AM
[
Permlink
| « Hide
]
Chad Schoettger added a comment - 13/Dec/05 06:16 AM
attached web app to reproduce this issue.
Chad Schoettger made changes - 13/Dec/05 06:16 AM
Chad, from the repro application, what is both the expected and observed behavior here?
Adding 1.1 to the affects version.
Eddie O'Neil made changes - 13/Dec/05 06:22 AM
Appears to be a pageflow issue, assigning to Rich.
Chad Schoettger made changes - 16/Dec/05 02:23 AM
Hey Chad, when I run /Controller.jpf, I get the following output:
**** Enter: doRenderChart() **** **** Leave: doRenderChart() **** **** Enter: doRenderChart() **** **** Leave: doRenderChart() **** **** Enter: doRenderChart() **** **** Leave: doRenderChart() **** **** Enter: doRenderChart() **** **** Leave: doRenderChart() **** **** Enter: doRenderChart() **** **** Leave: doRenderChart() **** **** Enter: doRenderChart() **** **** Leave: doRenderChart() **** **** Enter: doRenderChart() **** **** Leave: doRenderChart() **** **** Enter: doRenderChart() **** **** Leave: doRenderChart() **** **** Enter: doRenderChart() **** **** Leave: doRenderChart() **** **** Enter: doRenderChart() **** **** Leave: doRenderChart() **** This seems OK -- what should I be looking for?
Rich Feit made changes - 16/Dec/05 06:36 AM
OK, I've actually added this code in my control:
@Context ResourceContext resourceContext; @EventHandler(field="resourceContext", eventSet=ResourceContext.ResourceEvents.class, eventName="onAcquire") public void onAcquire() { System.err.println("&&&&& onAcquire"); } @EventHandler(field="resourceContext", eventSet=ResourceContext.ResourceEvents.class, eventName="onRelease") public void onRelease() { System.err.println("&&&&& onRelease"); } So the question is, how *should* "&&&&& onAcquire" and "&&&&& onRelease" be interleaved in the rest of the output? You can kick this back to me with that info -- thanks. Chad, I'm attaching a Controls-only webapp that proves one of three things:
1) This is fundamentally a problem with Controls. 2) At least one piece of the problem is within Controls. 3) The NetUI framework is using Controls incorrectly, since it uses Controls in the way that this repro app uses Controls. Hopefully you or someone else can tell me whether it's 1/2, or 3. :) Basically, the issue involves using the *same instance* of a Control from two separate threads. To reproduce the problem: - Deploy the attached app to Tomcat. - Hit http://localhost:8080/jira1028Simplified/one.jsp. - Make sure your Tomcat console is visible. - Click the "go" link in the browser (to eliminate variables, please use Firefox, not IE or Mozilla). - When you see "Click again!" on the console, click the "go" link again. You'll see the following output (the numbers are thread-IDs). Notice that there's only one call to each of onAcquire/onRelease (on the first thread), even though dummyControlMethod gets called from both threads. 34 onAcquire 34 begin dummyControlMethod 34 end dummyControlMethod 35 begin dummyControlMethod 34 onRelease 35 end dummyControlMethod
Rich Feit made changes - 16/Dec/05 10:09 AM
After further investigation this appears to be a problem with the ControlFilter and PageFlow.
Basically what is happening is: *) The bean context is being stored in the session. *) When the context's 'beginContext()' method is called, it is passed the current request and response as parameters - which ties the bean context to a particular servlet request/response. *) If another thread with the same session makes a request, the same bean context is used but if the bean context associated with the first thread has not completed its servlet request/response information is overwritten by the second thread's request. I belive that the core isssue here is that it is improper to store a bean context in a session, since the bean context works on a per-request scope, but at any given time there may be multiple requests made on a single session.\ My recommendation would be to remove the ability to store the bean context in the session, and just create a new bean context for each request recieved. This is a fairly straightforward modification to the ControlFilter but may need some additional investigation on the page flow side of things. The main question would be: is it OK to maintain a reference to a control that lives longer than a context that it's resided in? Since Control member variables in page flows end up stored in the session, each one would get put into a different context for each request. If it's OK to have a longer-lived Control, then it sounds like this will work.
If you take that approach (making it invalid to store the context in the session), then I assume you'd deprecate the Servlet init param that enables this behavior in ServletBeanContext?
Commited fix to ControlFilter for this bug. Fix consists of removing the 'useSession' initParam for the ControlFiler and creating a new ControlBeanContext for each request the ControlFilter recieves.
This fix in no way resolves this issue for pageflows.
Daryl Olander made changes - 24/Jan/06 03:10 AM
I reworked how the ControlContainerContext inside of the page flow runtime works to fix a number of problems that could have caused problems. The following is a brief description of this fix.
There are now two sets of ControlContainerContext (CCC) objects. For page flows and faces backing files, the CCC is scoped into the lifetime of the page flow. For all shared flows (and global app) there is a single CCC. In order to handle the property beginContext/endContext, we now do the beginContext/endContext in the three single threaded execution sections where page flow code runs. These are the around onCreate, beforeAction/Action/afterAction, and then JSP rendering. In each of these sections will will run beginContext and endContext. In addition, there is a single lock object that is obtained to gain access to the shared flow CCC. The result is that we now provide single threaded access to a shared flow (assuming that there is a control in some shared flow). In addition, we will serialize execution of thread within the session. We also run the proper resource event lifecycle on the controls.
Daryl Olander made changes - 25/Jan/06 05:46 AM
Alejandro Ramirez made changes - 02/Feb/06 07:02 AM
re-run the web app, the connection closed exception does not happen anymore.
Yongqin Xu made changes - 09/Feb/06 02:45 AM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Controls in pageflows do not appear to be receiving lifecycle events in the proper order
