asked on geronimo@ if we can drop this class. About perf I think moving reflection check to findXXX methods (for impl and subclasses) will do the trick since we'll call it for very few classes compared to current impl which checks the whole 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 17:10 GMT+02:00 Romain Manni-Bucau <[email protected]>: > yes so why 2 threads? > > > 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 16:53 GMT+02:00 Andy Gumbrecht <[email protected]>: >> They depend on a latch, you need another look. >> >> >> On 08/08/2014 16:42, Romain Manni-Bucau wrote: >>> >>> 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 <[email protected]>: >>>> >>>> +1 >>>> >>>> -- >>>> Jean-Louis Monteiro >>>> http://twitter.com/jlouismonteiro >>>> http://www.tomitribe.com >>>> >>>> >>>> On Fri, Aug 8, 2014 at 3:17 PM, Andy Gumbrecht <[email protected]> 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 >>>>>> <[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.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 >>>>>>>> [email protected] >>>>>>>> https://twitter.com/AndyGeeDe >>>>>>>> >>>>>>>> TomEE treibt Tomitribe! | http://tomee.apache.org >>>>>>>> >>>>>>>> >>> >>
