Thanks Martin Deh from A-Team for identifying it is a recently reported bug.
To summarize the problem: during a load testing (>1000 users attempt) on a WebCenter framework application developed with content presenter task flows, the performance (page response time) was greatly impacted by a series of parked threads. The issue was not produced in the 1000 users test. The parked threads took from >30 seconds to minutes to resume. By investigating the stack trace, the culprit is pointed to java.util.concurrent.locks.ReentrantLock.lock() which is called by UCMBridge.getAccessLevel(IdcContext, DataObject, ITrace).
This issue has been filed as a bug (Bug 17330713) and the patch/fix is to be provided soon (Update: the patch is available as of date 11/4/2013 for 11.1.1.7.1)
The following shows a graphic indication of the parked threads (gray) through the tests. As you can see, the gray areas took the majority of the timeline.
Here is the stack track of one particular parked thread:
Look further down the stack trace, you will find the issue was from a call on ContentPresenterBackingBean. So it's obvious enough to tell it's caused by content presenter task flow. There is so far no evidence that other document task flow would cause the same issue.
To summarize the problem: during a load testing (>1000 users attempt) on a WebCenter framework application developed with content presenter task flows, the performance (page response time) was greatly impacted by a series of parked threads. The issue was not produced in the 1000 users test. The parked threads took from >30 seconds to minutes to resume. By investigating the stack trace, the culprit is pointed to java.util.concurrent.locks.ReentrantLock.lock() which is called by UCMBridge.getAccessLevel(IdcContext, DataObject, ITrace).
This issue has been filed as a bug (Bug 17330713) and the patch/fix is to be provided soon (Update: the patch is available as of date 11/4/2013 for 11.1.1.7.1)
The following shows a graphic indication of the parked threads (gray) through the tests. As you can see, the gray areas took the majority of the timeline.
Here is the stack track of one particular parked thread:
Look further down the stack trace, you will find the issue was from a call on ContentPresenterBackingBean. So it's obvious enough to tell it's caused by content presenter task flow. There is so far no evidence that other document task flow would cause the same issue.
Comments