Re: Naïve Tomcat experiment--does this indicate pinning?

[Alan Bateman]

On 05/05/2022 06:19, Cay Horstmann wrote:
>
> The servlet sleeps for (int) (1000 * Math.random()) millis. I take a 
> thread dump right after firing 200 requests. 9 threads park on sleep 
> with a stack trace shown below. The rest show up as
>
>          {
>            "tid": 616,
>            "name": "myfactory-562",
>            "stack": [
>            ]
>          },
>
> which I guess means "Not started yet". 

The stack trace of an unstarted or terminated Thread is empty. In this 
case it's probably threads that have terminated. This has improved a bit 
since the last EA build was published so are less likely to see threads 
that terminate at just around the time that you take a thread dump.



> I could not see anything that Tomcat does wrong. Tomcat has launched 
> the virtual threads for all requests, and none of them shows up as 
> doing anything nefarious. I expected to see 200 sleeping virtual 
> threads, or a bunch of messages about pinned threads. (I ran with 
> -Djdk.tracePinnedThreads=full)
>
> There were none in these runs. But wait, way back when, I did see a 
> couple. And this time I happen to notice that line had a curious arrow 
> like this:
>
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) 
> <== monitors:1
>
> Looking at SocketProcessorBase.run, I found a synchronized block. 
> Replacing it with a ReentrantLock solved the problem.
>
> So there is a happy ending, but couldn't it have been happier? Would 
> it be possible to report such a problem more clearly?

I'm good to hear you found the issue.

Running with -Djdk.tracePinnedThreads=full prints the full stack trace 
and may not be easy to spot the "<== monitors:1" message. The other 
value is "short" (-Djdk.tracePinnedThreads=short) which will limit the 
output to the native frames or frames holding monitors. The other 
alternative is obtain a JFR recording.

-Alan