Details
-
Type:
Bug
-
Status: Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 1.6.2, 1.7Beta1
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Environment:All
-
Workaround Exists:Yes
-
Workaround Description:Once the application server is up, hit the application with a browser and once the application comes up, then launch the scripts.
Description
Using JMeter to simulate a number of users, it's easy to create several instances of RenderManager, or likely any other 'application' scoped bean.
Using Timezone3 with server push serving up a clock, I launch 10 users in 10 seconds and wind up with 6 RenderManager instances being created. Each of the 6 create a RenderHub which in turn creates their 15 or so RenderThreads. Eventually, all but one reference to a RenderManager is GC'd, but the Threads created never go away.
I suspect that there is some code like:
if (Bean == null) {
Bean = longRunningBeanConstructionProcess();
}
or some such race condition that is allowing this to occur.
This is exacerbated by JMeter, in that there is the tendency to start too many threads nearly simultaneously, and there is no problem once the first renderManager is created and in place, so it's not a killer problem at the moment.
Using Timezone3 with server push serving up a clock, I launch 10 users in 10 seconds and wind up with 6 RenderManager instances being created. Each of the 6 create a RenderHub which in turn creates their 15 or so RenderThreads. Eventually, all but one reference to a RenderManager is GC'd, but the Threads created never go away.
I suspect that there is some code like:
if (Bean == null) {
Bean = longRunningBeanConstructionProcess();
}
or some such race condition that is allowing this to occur.
This is exacerbated by JMeter, in that there is the tendency to start too many threads nearly simultaneously, and there is no problem once the first renderManager is created and in place, so it's not a killer problem at the moment.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
I've been able to duplicate this problem with a strictly JSF application as well, so I don't think this is an ICEfaces bug. I just have a trivial application and I can easily generate the problem using JMeter.
I've posted a question on the JSF forums here: http://forum.java.sun.com/thread.jspa?messageID=10251657�
and we'll see what the exciting conclusion is.
As an aside, their advice was to use @PostConstruct and @PreDestroy in an effort to fix the problem. These might be useful annotations for other aspects of ICEfaces. The only difficulty is that they require source=1.5 in the build script, which is a major effort for RenderManager due to the way the async.render package is accessed from outside.