PIP-234: Support using shared thread pool across multiple Pulsar client instance
- Dominant language
- Java
- Stars
- 15.3k
- Forks
- 3.8k
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 160
Description
### Motivation
The Pulsar client mainly has three thread pools that cooperate with each other to complete the message publishing and consumption of messages.
- IO threads - Used for handling network packets from the broker
- Internal threads - Used for handling internal tasks such as moving the received messages to the internal receiver queue and pulling out the message from the receiver queue to return to users. And the Java client is optimized by the lock-free principle; each consumer will use a pinned internal thread to reduce the lock overhead.
- External threads - Used by the message listener
All the above thread pools will be created automatically after a Pulsar client instance has been created.
But for some cases, users need to create multiple Pulsar client instances in a JVM process due to different authentications or others. Each client will have exclusive thread pools, which will cause unreasonable thread usage, waste memory, and potential performance degradation.
It is not a serious problem for previous releases with the default configurations because the thread pool will only have 1 thread by default. But it also doesn't make sense that we only have one thread for each thread pool. We have discussed this part under this [thread](https://lists.apache.org/thread/5obfm17g58n3dnbzyxg57vokgmwyp6hx)
So this proposal will provide a new possibility for users that require multiple Pulsar client instances in one JVM process to use the shared thread pools across multiple Pulsar client instances.
### Goal
Provide public API to use the shared thread pool across multiple Pulsar client instances in one JVM process
- IO threads
- Internal threads
- External threads
BTW, we already have such an ability internally. It was just hidden for users. Please take a look at #12037 and #13839 to get more details.
### API Changes
The following APIs will be introduced to the Java Client when creating a Client instance
```java
PulsarClient.builder()
.eventLoopGroup(ioEventLoopGroup)
.internalExecutorProvider(sharedInternalExecutorProvider)
.externalExecutorProvider(sharedExternalExecutorProvider)
.scheduledExecutorProvider(sharedScheduledExecutorProvider)
```
### Mailing list threads
* https://lists.apache.org/thread/5jw06hqlmwnrgvbn9lfom1vkwhwqwwd4
* https://lists.apache.org/thread/5obfm17g58n3dnbzyxg57vokgmwyp6hx
Contributor guide
Research direction
Start with the Java Client builder and review the API changes listed in the issue for shared IO, internal, external, and scheduled executor providers. Read issues #12037 and #13839 for the existing internal capability. Done means the shared thread-pool option is exposed as a public API for multiple Pulsar client instances.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend-api-design, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100