
<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <br>

    <br>

    <div class="moz-cite-prefix">On 13/08/2024 16:34, robert engels

      wrote:<br>

    </div>

    <blockquote type="cite" cite="mid:2B441D52-0910-47E4-8656-BCFE26964965@icloud.com">

      <pre class="moz-quote-pre" wrap="">I did. It didn’t make any difference. I checked the thread dump as well and the extras were created. 


Surprised that lowering the priority didn’t help - so now I need to think about other options. It feels like something when the carriers can use all the cores that the poller is prevented from running - like some sort of lock being held by the carrier/vt and do it thrashes around until it eventually gets a chance. 


</pre>

    </blockquote>

    With pollerMode=2 then the the work is done on virtual threads so I

    assume you don't see the master poller stealing CPU cycles.<br>

    <br>

    In any case, what you describe sounds a bit like bursty usage where

    all FJP workers are scanning for work before parking, and/or

    something else that may be macOS specific when running out of some

    resource. I suspect tuning the networking params to remove the

    errors/timeouts might make it a bit easier to study.<br>

    <br>

    -Alan<br>

    <br>

    <br>

  </body>

</html>