New liveness probe to check for deadlocked threads

[abrenk]

This is a new liveness probe that uses the ThreadMXBean to check for deadlocked threads.

It is currently enabled by default like the other probes in this module, as long as endpoints.health.deadlocked-threads.enabled is not set to false. There is no other configuration.

As one would expect the health status is set to DOWN if any deadlocked threads are found and their ThreadInfo including a formatted stacktrace are given in the details.

[CLAassistant]

All committers have signed the CLA.

[abrenk]

This is an example for the details of a deadlock:

{
    "name": "example-app",
    "status": "DOWN",
    "details": {
        "deadlockedThreads": {
            "name": "example-app",
            "status": "DOWN",
            "details": [
                {
                    "threadId": "60",
                    "threadName": "Thread-0",
                    "threadState": "BLOCKED",
                    "daemon": "false",
                    "priority": "5",
                    "suspended": "false",
                    "inNative": "false",
                    "lockName": "java.lang.Object@7d10b1ca",
                    "lockOwnerName": "Thread-1",
                    "lockOwnerId": "61",
                    "lockedSynchronizers": [],
                    "stackTrace": "app//com.example.Deadlock.lambda$new$0(Deadlock.java:27)\n-  blocked on java.lang.Object@7d10b1ca\n-  locked java.lang.Object@4505ea74\napp//com.example.Deadlock$$Lambda/0x000001906948b360.run(Unknown Source)\njava.base@21/java.lang.Thread.runWith(Thread.java:1596)\njava.base@21/java.lang.Thread.run(Thread.java:1583)\n"
                },
                {
                    "threadId": "61",
                    "threadName": "Thread-1",
                    "threadState": "BLOCKED",
                    "daemon": "false",
                    "priority": "5",
                    "suspended": "false",
                    "inNative": "false",
                    "lockName": "java.lang.Object@4505ea74",
                    "lockOwnerName": "Thread-0",
                    "lockOwnerId": "60",
                    "lockedSynchronizers": [],
                    "stackTrace": "app//com.example.Deadlock.lambda$new$1(Deadlock.java:43)\n-  blocked on java.lang.Object@4505ea74\n-  locked java.lang.Object@7d10b1ca\napp//com.example.Deadlock$$Lambda/0x000001906948b580.run(Unknown Source)\njava.base@21/java.lang.Thread.runWith(Thread.java:1596)\njava.base@21/java.lang.Thread.run(Thread.java:1583)\n"
                }
            ]
        }
    }
}

[graemerocher]

thanks can you target the 4.8.x branch?

[abrenk]

I have rebased onto the 4.8.x branch.

[abrenk]

I will add some documentation to healthEndpoint.adoc tomorrow.

[abrenk]

I have adapted the HealthAggregator unit tests to the new indicator because the ordered list of messages now contains one element more.

[sdelamo]

@abrenk Thanks for your contribution. I have added a functional test.

[graemerocher]

Seems it is failing the native tests, not sure if this API for this is different with Native Image

[sdelamo]

ThreadMXBean implementation is not supported in Native Image

[sdelamo]

ThreadMXBean implementation is not supported in Native Image

I have used official Graal SDK ImageInfo::inImageCode to load the health indicator only on JVM.

However, @yawkat pointed me to Jackson Databind's NativeImageUtil as an alternative to check if we are on native image. Personally, I think it is best to use the official API and one less to maintain. A drawback is that I added the org.graalvm.sdk:nativeimage as a transitive dependency of management.

@graemerocher what do you think?