michaeljmarshall commented on a change in pull request #13839:
URL: https://github.com/apache/pulsar/pull/13839#discussion_r789183782
##########
File path:
pulsar-broker/src/main/java/org/apache/pulsar/broker/PulsarService.java
##########
@@ -318,6 +323,18 @@ public PulsarService(ServiceConfiguration config,
this.ioEventLoopGroup =
EventLoopUtil.newEventLoopGroup(config.getNumIOThreads(),
config.isEnableBusyWait(),
new DefaultThreadFactory("pulsar-io"));
+ // the internal executor is not used in the broker client or
replication clients since this executor is
+ // used for consumers and the transaction support in the client.
+ // since an instance is required, a single threaded shared instance is
used for all broker client instances
+ this.brokerClientSharedInternalExecutorProvider =
+ new ExecutorProvider(1,
"broker-client-shared-internal-executor");
+ // the external executor is not used in the broker client or
replication clients since this executor is
+ // used for consumer listeners.
+ // since an instance is required, a single threaded shared instance is
used for all broker client instances
Review comment:
> Yes the client isn't optimal, but I doubt that it causes an actual
measurable overhead. I think that the thread is just pinned out of the single
shared thread and nothing will get run on it (in the current usage patterns
when client is used in the broker).
I was thinking about user applications that have many consumers. I just
looked a bit closer, and the upper limit here is `NumListenerThreads` in the
client configuration. That is the max number of threads a client will spawn for
consumer listeners. Was this a problem in the broker because we have many
clients?
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
