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 >>>>>>> >>>>>>> >> >
