quarkus-bot[bot]
commented
2 weeks ago /cc @Ladicek (arc), @manovotn (arc), @mkouba (arc)
Open vsevel opened 2 weeks ago
quarkus-bot[bot]
commented
2 weeks ago /cc @Ladicek (arc), @manovotn (arc), @mkouba (arc)
mkouba
commented
2 weeks ago Hm, I thought that java.util.concurrent.locks.ReentrantLock is the recommended way to replace the synchronized blocks in order to avoid pinning :thinking:.
CC @mariofusco @cescoffier @xstefank
vsevel
commented
2 weeks ago I believe so as well. I do not know if there is synchronized or a wait hidden in the stack. would we see it in this stacktrace?
I suppose so according to PinnedThreadPrinter.printStackTrace():
private static void printStackTrace(List<LiveStackFrame> stack,
PrintStream out,
boolean printAll) {
out.println(Thread.currentThread());
for (LiveStackFrame frame : stack) {
var ste = frame.toStackTraceElement();
int monitorCount = frame.getMonitors().length;
if (monitorCount > 0) {
out.format(" %s <== monitors:%d%n", ste, monitorCount);
} else if (frame.isNativeMethod() || printAll) {
out.format(" %s%n", ste);
}
}
}
xstefank
commented
2 weeks ago Most likely there is. ReentrantLock is working.
vsevel
commented
2 weeks ago Most likely there is.
do you know how to chase it?
xstefank
commented
1 week ago @vsevel I don't think there is a general way how to chase it. Can you provide me with a reproducer? Just to be sure there are no monitors in your business code? I can't reproduce it.
mariofusco
commented
1 week ago @vsevel I could also give a look at this, but I agree with @xstefank on the fact that we need a reproducer.
vsevel
commented
1 week ago it is unlikely that I will be able to give a reproducer. I am totally fine if at some point we close it with "cannot reproduce". I still wanted to create the issue so that we have a place to provide as much context as possible, and that is something that can be searched by others that experience the same issue.
vsevel
commented
1 week ago a bit more information. I looked at the app that was experiencing that particular issue, with that exact stacktrace.
it all happened on the same day. and in 2 occasions I looked at the error occurred just after startup.
and what is particularly disturbing is that in these 2 cases, the application experienced multiple exceptions and timeouts, and eventually killed shortly after because of the SmallRye Reactive Messaging - liveness check being down. one time it was because of org.jboss.resteasy.reactive.ClientWebApplicationException: Received: ', status code 401' when invoking ..., and the other time it was {"name":"SmallRye Reactive Messaging - liveness check","status":"DOWN","data":{"x":"[OK]","x":"[KO] - Multiple exceptions caught:\n\t[Exception 0] org.jboss.resteasy.reactive.ClientWebApplicationException: Received: 'Bad Gateway, status code 502' when invoking:.
I do not know what is causing the other.
franz1981
commented
1 week ago I see io.smallrye.faulttolerance.core.apiimpl.LazyFaultTolerance.call(LazyFaultTolerance.java:28) <== monitors:1
Which have a monitor there?
Describe the bug
I detected the following thread pinning:
we do not believe we are doing any native call in our app. similar issue to https://github.com/quarkusio/quarkus/issues/41313 how can we investigate this?
Expected behavior
No response
Actual behavior
No response
How to Reproduce?
No response
Output of
uname -aorverNo response
Output of
java -versionNo response
Quarkus version or git rev
No response
Build tool (ie. output of
mvnw --versionorgradlew --version)No response
Additional information
No response