[
https://jira.nuxeo.org/browse/NXP-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anahide Tchertchian updated NXP-4701:
-------------------------------------
Description:
When producing certains errors (reproduced with any error thrown during the JSF
invoke application phase), a reetrant lock is placed on current conversation,
for current thread, that is never released.
Next locks with same thread and conversation go ok, since lock is already
acquired for current thread.
Problem becomes visible when another thread tries to acquire the lock for the
same conversation: thread is blocked as it cannot acquire the lock still held
by another thread.
Reproducing the problem is quite difficult, as it's not possible to force usage
of another thread. Reducing the max number of tomcat threads to "2" helps (in
server/default/deploy/jboss-web.deployer/server.xml), as well as using jmeter
usage to get more requests.
Setting a low conversation timout and high concurrent request timeout in
nuxeo.ear/OSGI-INF/templates/components.xml can also help:
<component name="org.jboss.seam.core.manager">
<!-- 2min -->
<property name="conversationTimeout">120000</property>
<!-- 20s concurrent request timeout -->
<property name="concurrentRequestTimeout">20000</property>
</component>
When problem occurs, thread is not released until seam Manager logs show:
"destroying conversation with garbage lock: 0NXMAIN", a sign that conversation
timeout has been reached, and that some cleanup of locks is done.
Spotting the cause of the problem is easier, patching ConversationEntry method
in jboss-seam to get more logs:
public boolean lock() //not synchronized!
{
try
{
boolean res = lock.tryLock(
Manager.instance().getConcurrentRequestTimeout(), TimeUnit.MILLISECONDS );
if (!res) {
log.debug(id+ " " + Thread.currentThread().getId() + " lockfailed
"+ lock.getHoldCount()+ " "+lock.isHeldByCurrentThread());
} else {
log.debug(id+ " " + Thread.currentThread().getId() + " lock "+
lock.getHoldCount()+ " "+lock.isHeldByCurrentThread());
}
return res;
}
catch (InterruptedException ie)
{
throw new RuntimeException(ie);
}
}
These logs show that the hold count is incremented by 1 at each error, and does
not decrease.
There have been some seam related issues in version 2.0.3 CR1:
https://jira.jboss.org/jira/browse/JBSEAM-3680
https://jira.jboss.org/jira/browse/JBSEAM-1277
Applying the patch given in JBSEAM-1277 solves the problem:
http://fisheye.jboss.org/changelog/Seam/?cs=9096
When error is produced, SeamPhaseListener puts a lock on conversation after the
"restore view" phase, but it never gets to the "render response" phase where
lock should be released. The given fix makes the ExceptionFilter cleanup this
lock when handling the error.
was:
When producing certains errors (reproduced with any error thrown during the JSF
invoke application phase), a reetrant lock is placed on current conversation,
for current thread, that is never released.
Next locks with same thread and conversation go ok, since lock is already
acquired for current thread.
Problem becomes visible when another thread tries to acquire the lock for the
same conversation: thread is blocked as it cannot acquire the lock still held
by another thread.
Reproducing the problem is quite difficult, as it's not possible to force usage
of another thread. Reducing the max number of tomcat threads to "2" helps (in
server/default/deploy/jboss-web.deployer/server.xml), as well as using jmeter
usage to get more requests.
Setting a low conversation timout and high concurrent request timeout in
nuxeo.ear/OSGI-INF/templates/components.xml can also help:
<component name="org.jboss.seam.core.manager">
<!-- 2min -->
<property name="conversationTimeout">120000</property>
<!-- 20s concurrent request timeout -->
<property name="concurrentRequestTimeout">20000</property>
</component>
Spotting the cause of the problem is easier, patching ConversationEntry method
in jboss-seam to get more logs:
public boolean lock() //not synchronized!
{
try
{
boolean res = lock.tryLock(
Manager.instance().getConcurrentRequestTimeout(), TimeUnit.MILLISECONDS );
if (!res) {
log.debug(id+ " " + Thread.currentThread().getId() + " lockfailed
"+ lock.getHoldCount()+ " "+lock.isHeldByCurrentThread());
} else {
log.debug(id+ " " + Thread.currentThread().getId() + " lock "+
lock.getHoldCount()+ " "+lock.isHeldByCurrentThread());
}
return res;
}
catch (InterruptedException ie)
{
throw new RuntimeException(ie);
}
}
These logs show that the hold count is incremented by 1 at each error, and does
not decrease.
There have been some seam related issues in version 2.0.3 CR1:
https://jira.jboss.org/jira/browse/JBSEAM-3680
https://jira.jboss.org/jira/browse/JBSEAM-1277
Applying the patch given in JBSEAM-1277 solves the problem:
http://fisheye.jboss.org/changelog/Seam/?cs=9096
When error is produced, SeamPhaseListener puts a lock on conversation after the
"restore view" phase, but it never gets to the "render response" phase where
lock should be released. The given fix makes the ExceptionFilter cleanup this
lock when handling the error.
> Fix thread blocked by seam conversation handling
> ------------------------------------------------
>
> Key: NXP-4701
> URL: https://jira.nuxeo.org/browse/NXP-4701
> Project: Nuxeo Enterprise Platform
> Issue Type: Bug
> Affects Versions: 5.3 GA
> Reporter: Anahide Tchertchian
> Assignee: Anahide Tchertchian
> Priority: Major
> Fix For: 5.3.1
>
> Attachments: jboss-seam-2.0.3.CR1-NX3.jar,
> jboss-seam-2.0.3.CR1.NX3.diff, stack-NXP-4701-1.txt, stack-NXP-4701-2.txt
>
>
> When producing certains errors (reproduced with any error thrown during the
> JSF invoke application phase), a reetrant lock is placed on current
> conversation, for current thread, that is never released.
> Next locks with same thread and conversation go ok, since lock is already
> acquired for current thread.
> Problem becomes visible when another thread tries to acquire the lock for the
> same conversation: thread is blocked as it cannot acquire the lock still held
> by another thread.
> Reproducing the problem is quite difficult, as it's not possible to force
> usage of another thread. Reducing the max number of tomcat threads to "2"
> helps (in server/default/deploy/jboss-web.deployer/server.xml), as well as
> using jmeter usage to get more requests.
> Setting a low conversation timout and high concurrent request timeout in
> nuxeo.ear/OSGI-INF/templates/components.xml can also help:
> <component name="org.jboss.seam.core.manager">
> <!-- 2min -->
> <property name="conversationTimeout">120000</property>
> <!-- 20s concurrent request timeout -->
> <property name="concurrentRequestTimeout">20000</property>
> </component>
> When problem occurs, thread is not released until seam Manager logs show:
> "destroying conversation with garbage lock: 0NXMAIN", a sign that
> conversation timeout has been reached, and that some cleanup of locks is done.
> Spotting the cause of the problem is easier, patching ConversationEntry
> method in jboss-seam to get more logs:
> public boolean lock() //not synchronized!
> {
> try
> {
> boolean res = lock.tryLock(
> Manager.instance().getConcurrentRequestTimeout(), TimeUnit.MILLISECONDS );
> if (!res) {
> log.debug(id+ " " + Thread.currentThread().getId() + "
> lockfailed "+ lock.getHoldCount()+ " "+lock.isHeldByCurrentThread());
> } else {
> log.debug(id+ " " + Thread.currentThread().getId() + " lock "+
> lock.getHoldCount()+ " "+lock.isHeldByCurrentThread());
> }
> return res;
> }
> catch (InterruptedException ie)
> {
> throw new RuntimeException(ie);
> }
> }
> These logs show that the hold count is incremented by 1 at each error, and
> does not decrease.
> There have been some seam related issues in version 2.0.3 CR1:
> https://jira.jboss.org/jira/browse/JBSEAM-3680
> https://jira.jboss.org/jira/browse/JBSEAM-1277
> Applying the patch given in JBSEAM-1277 solves the problem:
> http://fisheye.jboss.org/changelog/Seam/?cs=9096
> When error is produced, SeamPhaseListener puts a lock on conversation after
> the "restore view" phase, but it never gets to the "render response" phase
> where lock should be released. The given fix makes the ExceptionFilter
> cleanup this lock when handling the error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.nuxeo.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
ECM-tickets mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
