thread deadlocks in Component.getInstanceFromFactory

[jeanluc]

Has anyone else seen a deadlock here?

Found one Java-level deadlock:
=============================
"http-0.0.0.0-8280-97":
  waiting for ownable synchronizer 0x00002aaad2b1ca38, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
  which is held by "http-0.0.0.0-8280-20"
"http-0.0.0.0-8280-20":
  waiting for ownable synchronizer 0x00002aaacf603b18, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
  which is held by "http-0.0.0.0-8280-46"
"http-0.0.0.0-8280-46":
  waiting for ownable synchronizer 0x00002aaad2b1ca38, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
  which is held by "http-0.0.0.0-8280-20"

The common part of all stack traces is:

     at sun.misc.Unsafe.park(Native Method)
     - parking to wait for  <0x00002aaad2b1ca38> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:842)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1178)
     at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
     at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
     at org.jboss.seam.Component.getInstanceFromFactory(Component.java:2082)
     at org.jboss.seam.Component.getInstance(Component.java:2014)
     at org.jboss.seam.Component.getInstance(Component.java:1986)
     at org.jboss.seam.Component.getInstance(Component.java:1980)

I checked in the source but don't have an explanation yet. For a while I thought it was related to this Seam bug (https://issues.jboss.org/browse/JBSEAM-4669) but am not sure anymore.

[titou09]

It looks very similar

What version of seam are you using?

I am the author of JBSEAM-4669. You should also look at  JBSEAM-2419

As you can see in the comments I have never been confortable with the proposed patch but was not in position to prove that the patch was not correct. Maybe you've found tye right test case for that...

Yous should try to sketch what factories are implied in the deadlock by looking at the tracebacks on locked threads

[jeanluc]

Hi Dennis,

We use 2.2.1.CR2.

The deadlock happened in a training environment; we haven't been able to reproduce it elsewhere (but the application is not yet released to production). The load was low (about 15 users).

We suspect it's the conversation factories but am still a bit puzzled as the lock is not on a conversation itself (which would have been understandable, given that Seam synchronizes requests on conversations), but on that static lock factory.

Below is an excerpt from Seam's source.

package org.jboss.seam;

@Scope(ScopeType.APPLICATION)
public class Component extends Model {
   static ReentrantLock factoryLock = new ReentrantLock(); //this is the lock 

...

   private static Object getInstanceFromFactory(String name, ScopeType scope) {
            Object factory = Component.getInstance(factoryMethod.getComponent().getName(), true );
            factoryLock.lock(); //and this is where it locks

I'll try go get more details if I can reproduce it.

[mana.hotmana76.gmail.com]

I will really appreciate your test case if you reproduce it.

[oskutka]

Hello Jean Luc,

do you have full stack traces of all (relevant) threads running at the moment of the deadlock?

--
Ondra Skutka

[jeanluc]

Unfortunately not.

Ondrej Skutka wrote on Jan 26, 2011 09:16:


Hello Jean Luc,

do you have full stack traces of all (relevant) threads running at the moment of the deadlock?

--
Ondra Skutka