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 <andy...@gmx.de>:
> 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 <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
>>>>>>>
>>>>>>>
>>
>

Reply via email to