I will go for live lock as well. But yes, stack dumps lie. I think jstack -F might be harsher and give a different result.
But that said, you still have a deadlock. As mentioned "New I/O worker #1810850" waiting on 0x0000000080ac88f0 is held by "New I/O worker #1810853" <-- waiting for one another "New I/O worker #1810853" waiting on 0x00000000802ba7f8 is held by "New I/O worker #1810850" <-- waiting for one another My question would be: Why is kudu wanting to get so much SSLContexts? Can't it reuse them? (I don't know the api well, so maybe it's normal) On 11 October 2017 at 06:48, Kirk Pepperdine <[email protected]> wrote: > My vote is for live lock.. but that would be conditional on seeing all the > stack traces. > > — Kirk > > On Oct 11, 2017, at 12:07 PM, Todd Lipcon <[email protected]> wrote: > > On Wed, Oct 11, 2017 at 12:29 AM, Kirk Pepperdine <[email protected]> > wrote: > >> Not at all off topic… first, thread dumps lie like a rug… and here is why… >> >> for each thread { >> safe point >> create stack trace for that thread >> release threads from safe point >> } >> >> And while rugs may attempt to cover the debris that you’ve swept under >> them, that debris leaves a clearly visible lump that suggests that you have >> a congestion problem on locks in both sun.security.provider.Sun and >> java.lang.Class…. What could possibly go wrong? >> > > Interesting. I remember investigating this back in the Java 6 days and at > that time 'jstack -l' caused a global safepoint before iterating over the > threads, and then only resumed upon completion (implemented by > VM_ThreadDump in vm_operations.cpp). It appears that in JDK 7 this was > switched over to the behavior that you describe. > > Either way, I'm looking at about 10 stack traces taken over a period of 3 > minutes and they have 100% identical "java-level deadlock" output. So I > suppose it's possible that they are live-locked on the same sets of locks > in the exact same threads but seems fairly unlikely. > > As for the congestion problem, I did find this JDK bug the other day: > https://bugs.openjdk.java.net/browse/JDK-8133070 which aims to reduce > contention, but no mention of a deadlock. We'll probably ask the customer > to bump to a newer JDK with this fix and see if it magically goes away. > > -Todd > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
