Re: Deadlock from AsynchronousInheritanceAnnotationFinder

Fri, 08 Aug 2014 06:18:32 -0700

OK, enough about the timeout - Please just concentrate on the FIX, which is the Executor not the timeout - Please just ignore the timeout part - If it should scan forever then please let it scan forever and not timeout!
I would still log something like 'Hmm, this took 5 years to complete - Are you sure it should have taken this long?', but that's just a suggestion, ignore it :-D , no timeouts! 


I would still like to see the threads run concurrently, and not one 
after the other. So not a single thread, rather two - Or at least two.


So +0 for the timeout, and +1 for the Executor.

wdyt?

On 08/08/2014 14:49, Jean-Louis Monteiro wrote:

Adding a timeout prevents the main thread from hanging for ever.
It's fine, but it somehow hides a bug here.
And remains the question: which value is reasonable?
- half an hour: fine maybe for big apps. What is a big app? Still an
eternity for tests or hello world
- 3s: fine for unit tests, but fail anyway for big apps.

2 situations:
- server not starting: we can easily notice it does not work and with the
kill -3 see where it comes from
- server starting anyway, and exception probably in logs. Best situation,
logs are checked and we can see the issue. Bad situation, we don't see
anything and app can more or less work, etc

Personally, I prefer to see the server to starting so that we know and we
can fix the server. This is true even in the CI and during dev.
The second one is probably better in users eyes, but not in mine cause that
means we have somewhere an unknown and tricky bug to find.

I'd say -1 as well probably.

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Fri, Aug 8, 2014 at 2:08 PM, Romain Manni-Bucau <[email protected]>
wrote:


Hi

Well I don't manage to comment on jira (proxy issue I guess)

latch.await(timeout, TimeUnit.SECONDS); is wrong IMHO (no timeout
should be needed otherwise we know we'll be broken for big apps, in
particular with 30s as default, we could put 30mn if we want to keep
it).

Personally I thought fixing it more on the long term getting rid of
async part since we now can't avoid link() and rewriting what is slow
if it is - depend a lot of the app, I'll try to use a deltaspike +
spring one to test it. Async impl was mainly a lazy solution when it
was not mandatory but since JavaEE 6 it is actually mandatory so we
need to tackle it properly. It should take next week I guess maximum.

wdyt?





Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-08-08 13:48 GMT+02:00 Andy Gumbrecht <[email protected]>:

Submitted a patch to XBean that fixes the issue:
https://issues.apache.org/jira/browse/XBEAN-271

Andy.


On 07/08/2014 20:52, David Blevins wrote:

Getting a deadlock on AsynchronousInheritanceAnnotationFinder when the
interface a class implements is not in the jar being scanned.

"main" #1 prio=5 os_prio=31 tid=0x00007f98ba812000 nid=0x1903 waiting on
condition [0x000000010862c000]
     java.lang.Thread.State: WAITING (parking)
         at sun.misc.Unsafe.park(Native Method)
         - parking to wait for  <0x000000016dd4ffc8> (a
java.util.concurrent.CountDownLatch$Sync)
         at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
         at


java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)

         at


java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)

         at


java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)

         at
java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
         at


org.apache.xbean.finder.AsynchronousInheritanceAnnotationFinder.join(AsynchronousInheritanceAnnotationFinder.java:111)

         at


org.apache.xbean.finder.AsynchronousInheritanceAnnotationFinder.findImplementations(AsynchronousInheritanceAnnotationFinder.java:97)

         at


org.apache.openejb.config.FinderFactory$ModuleLimitedFinder.findImplementations(FinderFactory.java:275)

         at


org.apache.tomee.catalina.OpenEJBContextConfig.processServletContainerInitializers(OpenEJBContextConfig.java:436)

         at


org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1265)

         at


org.apache.tomee.catalina.OpenEJBContextConfig.webConfig(OpenEJBContextConfig.java:363)

         at


org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:873)

         - locked <0x0000000118d204b8> (a
org.apache.tomee.catalina.OpenEJBContextConfig)
         at


org.apache.tomee.catalina.OpenEJBContextConfig.configureStart(OpenEJBContextConfig.java:113)

         at


org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:371)

         at


org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)

         at


org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)

         at


org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5355)

         - locked <0x0000000118d1f970> (a
org.apache.catalina.core.StandardContext)
         at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
         - locked <0x0000000118d1f970> (a
org.apache.catalina.core.StandardContext)
         at


org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)

         at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
         at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)

More importantly, when/why did we start using findImplementations?


-David




--
   Andy Gumbrecht

   http://www.tomitribe.com
   [email protected]
   https://twitter.com/AndyGeeDe

   TomEE treibt Tomitribe! | http://tomee.apache.org

























					Reply via email to