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