Adding that executor will introduce 2 additional context switches which would impact the performance.
> will do decompression of the payload on > the netty thread, which is a bad practice in my understanding. I would not categorize this as an anti-pattern: io-threads are there to do io work, and serialization & compression are definitely part of that. The important part is to avoid any blocking operations. -- Matteo Merli <matteo.me...@gmail.com> On Thu, Mar 16, 2023 at 5:01 PM Andrey Yegorov <ayego...@apache.org> wrote: > Hi, > > While looking through the code/thread dumps I noticed that decompression of > compressed payload happens on pulsar-client-io threads > Specifically: > > https://github.com/apache/pulsar/blob/80c5791b87482bee3392308ecef45f455f8de885/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ClientCnx.java#L495-L505 > handleMessage runs on the pulsar-client-io thread (used by netty) > and consumer.messageReceived() will do decompression of the payload on > the netty thread, which is a bad practice in my understanding. > > I am not very familiar with client's thread pools, are there any reasons > not to movemessageReceived() to internalPinnedExecutor, like > > consumer.internalPinnedExecutor.submit(() -> { > consumer.messageReceived(cmdMessage, headersAndPayload, > ClientCnx.this); > }); > > -- > Andrey >
