lhotari commented on PR #24745:
URL: https://github.com/apache/pulsar/pull/24745#issuecomment-3311373399
> In short, using a dedicated pool is okay. Continue using `ForkJoinPool` is
okay as well. I'm not against using a different thread pool for Caffine cache
only, so I didn't leave a comment or requested change to block merging this PR
as well. But this bug of JDK should not be a reason to remove `ForkJoinPool`
everywhere.
>
> I'd like to hear @lhotari's voice again
@BewareMyPower I think your previous comment already covered most and was a
really good answer.
Just adding a few items:
* There's already a problem in Pulsar that existing executors aren't
properly used and designed.
* For example, Netty IO threads should never be blocked, but they are:
https://github.com/apache/pulsar/issues/23865
* `synchronized` blocks under heavy concurrency will lead to contention
that blocks threads. When a Netty IO thread is blocked, it will cause a "noisy
neighbor" problem to all connections that share that connection
* An ordinary executor behaves in a different way than the ForkJoinPool.
ForkJoinPool can expand the number of threads when it detects blocking and
handle this efficiently. This might be relevant in some of the current usage of
executors.
* `MoreExecutor.directExecutor` shouldn't be used at all when
`refreshAfterWrite` is used with Caffeine, since it would defeat the purpose of
using background refreshing of the cached items. I don't see a reason why
someone would want to make an async Caffeine cache synchronous. That doesn't
make sense.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
