[
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.
Spotting 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
was:
In some cases, threads are blocked when lock a seam conversation: it seems that
the lock has never been released.
The exact use case to reproduce is still not clear, but it seems that:
- having only 2 threads helps reproducing
- throwing errors helps reproducing
There have been some seam related issues in version 2.0.3 CR1, for instance
when an error is issued, but these fixes seem already covered by nuxeo
excection mechanism. For reference:
https://jira.jboss.org/jira/browse/JBSEAM-3680
https://jira.jboss.org/jira/browse/JBSEAM-1277
> 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: 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.
> Spotting 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
--
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
