[
https://jira.nuxeo.org/browse/NXP-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anahide Tchertchian resolved NXP-4701.
--------------------------------------
Resolution: Fixed
done: http://hg.nuxeo.org/nuxeo/rev/eb56d77d1e8d
> 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
