Re: Deadlock from AsynchronousInheritanceAnnotationFinder

Andy Gumbrecht Fri, 08 Aug 2014 07:54:34 -0700

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

Re: Deadlock from AsynchronousInheritanceAnnotationFinder

Reply via email to