Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-6230

IDM hangs in shutdown waiting on promise.PromiseImpl.await

    Details

      Description

      When running tests OpenIDM is not shutting down and holding on to the database.

      Looking at the stack there are 2 qtp* threads waiting on a Promise when shutdown is performed.

      • waiting on <0x00000000c46486e8> (a org.forgerock.util.promise.PromiseImpl)
        at java.lang.Object.wait(Object.java:503)
        at org.forgerock.util.promise.PromiseImpl.await(PromiseImpl.java:618)
      • locked <0x00000000c46486e8> (a org.forgerock.util.promise.PromiseImpl)
        at org.forgerock.util.promise.PromiseImpl.getOrThrow(PromiseImpl.java:144)
        at org.forgerock.util.promise.PromiseImpl.getOrThrowUninterruptibly(PromiseImpl.java:161)
        at org.forgerock.json.resource.AbstractAsynchronousConnection.create(AbstractAsynchronousConnection.java:44)

      The other interesting thread is :

      "Thread-37" daemon prio=10 tid=0x00007fa610931800 nid=0x547 runnable [0x00007fa601fdd000]
      java.lang.Thread.State: RUNNABLE
      at java.net.SocketInputStream.socketRead0(Native Method)
      at java.net.SocketInputStream.read(SocketInputStream.java:152)
      at java.net.SocketInputStream.read(SocketInputStream.java:122)
      at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:100)
      at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:143)
      at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:173)

      • locked <0x00000000c41f19f0> (a com.mysql.jdbc.util.ReadAheadInputStream)

      Which is still running holding on to the database.

      Everything else is more or less parked.

      This started happening recently, and suspect it is down the the changes around async http client. I don't look at the code but i'm not surprised.

      We are probably missing a case to handle this and close/clean up on shutdown,

      Full jstack is attached.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jbranch Jon Branch
                Reporter:
                gary.williams Gary Williams
                QA Assignee:
                Tinghua.Xu
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: