I am no aware of any problem that would be causing a deadlock. Can you provide a thread dump to see what is thread locked? (e.g. jstack)
The problem is introduced by 3rd party classes de.softpro.doc.SignDocDocument and de.softpro.sdweb.SessionDocument -- are these your classes or 3rd party libs? Looks like 3 separate client requests are locking on the same objects and this creating a deadlock..
Good Morning Radoslav,
thank you for the analysis.
Yes, everything under de.softpro is from us (SOFTPRO GmbH).
How come that the same application works fine on JBoss 5 and 6 as well as Tomcat 6 and 7
without any issues and having the <distributable/> tag present.
Are there any significant differences in terms of clustering and this tag
when it comes to JBoss 7 ?
I was in a discussion with our developers this morning
and the problem seems to be identified.
There is a inconsistent locking strategy between some of the
methods within our application.
I have uploaded three log files which demonstrate the thread lock scenario:
The getDocumentType method - which always appears in all three situations - is locking in this order: SignDocDocument -> SessionDocument
The other methods (e.g. getMetaDataString, getField, convPagePointToCanvasPoint) are locking in exactly the opposite order: SessionDocument -> SignDocDocument
Thus a dead lock is created.
We presume that this is the issue here.
Are there any significant differences in terms of clustering and this tag when it comes to JBoss 7 ?
Sure. To begin with JBoss 7 was a major rewrite of many components, clustering did not change extremely, but there are definitely upgrades to major new versions of Infinispan, JGroups, Marshalling, etc.
IIUC you are accessing the session data concurrently, which needs to be dealt with very cautiously. Easy fix is to serialize all access to your session, possibly using a filter, but I am not sure if that's desirable.