Fix thread blocked by seam conversation handling

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.