these threads can't run concurrently since one depend on the other actually.
I booked some time next week to work on it and I'll try to remove this AsyncFinder which will now lead to more issues since we always have to use it. Normally if correctly implemented it shouldn't cost a lot to find implementations. @David: if you stil lhave the use case where it was so long please share it otherwise I'll start with a custom app. 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 15:32 GMT+02:00 Jean-Louis Monteiro <jlmonte...@tomitribe.com>: > +1 > > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com > > > On Fri, Aug 8, 2014 at 3:17 PM, Andy Gumbrecht <andy...@gmx.de> wrote: > >> 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 <rmannibu...@gmail.com >>> > >>> 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 <agumbre...@tomitribe.com>: >>>> >>>>> 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.AsynchronousInheritanceAnnotat >>>> ionFinder.findImplementations(AsynchronousInheritanceAnnotat >>>> ionFinder.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 >>>>> agumbre...@tomitribe.com >>>>> https://twitter.com/AndyGeeDe >>>>> >>>>> TomEE treibt Tomitribe! | http://tomee.apache.org >>>>> >>>>> >>
