Hi Shawn, The thread dump was generated on our production systems under high load. As this state caused OOMs I'll try to reproduce that case in our testing environment. I'll report as soon as I can reproduce that situation there.
Thanks, Michael On Wed, Jul 12, 2023 at 4:38 PM Shawn Heisey <apa...@elyograg.org> wrote: > On 7/11/23 21:50, michael dürr wrote: > > The solr version I'm running is 9.2.1 and it is not customized (not > > compiled from source). > > > > I scanned the whole stack trace for that object reference, but could only > > find threads that state that they are waiting for that lock as well. What > > exactly is the pattern I have to look for? > > The only stack trace that differs from that I posted before is this one > > (all other threads waiting for that lock have the "same" stacktrace as it > > was the same metrics call that caused their creation): > > It looks like Solr's thread dump handler does not include the info > required to cross-reference a lock. So that handler that returns a > thread dump needs a little more detail added to it. I can't look at it > today, that will need to wait until tomorrow. > > In the meantime, if you have Java itself generate a thread dump, then > that should contain the info required to cross reference the lock and > see what thread is holding the lock. > > Thanks, > Shawn >
