Global lock when creating beans

[vetler]

Hi,

We're having some performance issues in an application, and we are looking for culprits. This is a Java EE 6 application - EJBs, dependency injection, JSF, JPA, the works. While debugging, we think we're seeing that Weld has a global lock when creating bean instances. I'm referring to line 110 in org.jboss.weld.context.AbstractContext (https://github.com/weld/core/blob/1.1.8.Final/impl/src/main/java/org/jboss/weld/context/AbstractContext.java#L101). We're actually using 1.1.1-Final, though (but that particular code doesn't seem to have changed).

Please excuse me if I'm completely wrong here, and feel free to use nasty words when telling me how it's really done if I'm mistaken... but if there's a global lock when creating beans:

* how does this affect performance on high load systems, i.e. when creating lots and lots of beans?

* if a bean has many EJBs that are injected (as we do in our case), does this mean that the lock is held until all the EJBs are looked up and injected? In our case the EJBs are even on a remote server.

Here's a stack trace that lead us to wonder about this:

"http-thread-pool-8080(201)" daemon prio=10 tid=0x00002aaae089d800 nid=0x5971 waiting on condition [0x000000005e00c000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x000000068ba49870> (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.weld.context.AbstractContext.get(AbstractContext.java:114)
        at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
        at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:87)
       

But perhaps Weld works fine, and thisis just a symptom of other errors.

Thanks,

Vetle

[alesj]

Wow, 1.1.1, try 1.1.8. :-)

Or if you could, even 2.0.0.Alpha2.

Both should have a bunch of perf improvements.

[vetler]

Yeah, well... we're using Glassfish 3.1.1, which comes with 1.1.1 If we upgrade to Glassfish 3.1.2, we get Weld 1.1.4, which might not help much?

We would of course prefer not to manually upgrade to 1.1.8, but then again we might have to.

[vetler]

So... to answer my own question: I added a Thread.sleep(100000) to a method in a controller annotated with @PostConstruct, and yes - other beans can't be created, and hang until the sleeping thread is finished with the @PostConstruct method. Since we thought we could do some more heavy things in the @PostConstruct methods, this means we'll have to rethink this quite a bit.

Has this behaviour been changed in newer Weld releases? I took a quick look, and it looks like it's still the same.

[swd847]

This is still a problem, however it should only affect session and application scoped beans.

Would you be able to file a JIRA?

[vetler]

Yep, I'll try to create a minimal test case first.

Edit: Done! https://issues.jboss.org/browse/WELD-1157