-
Notifications
You must be signed in to change notification settings - Fork 137
Fix publish throttling and LoadManager API for pulsar upgrade #488
Fix publish throttling and LoadManager API for pulsar upgrade #488
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
…native#488) This PR upgrades pulsar dependency to 2.8.0-rc-202105092228, which has two major API changes. apache/pulsar#10391 changed `LoadManager` API so that `MetadataCache` is used instead of `ZookeeperCache` in this PR. apache/pulsar#7406 changed the throttling strategy. However, currently KoP is different from Pulsar that the produce and its callback may be in different threads. KoP calls `PersistentTopic#publishMessages` in a callback of `KafkaTopicManager#getTopic` if the returned future is not completed immediately. Otherwise, it's called just in the I/O thread. Therefore, here we still use a **channel based** publish bytes stats for throttling, while apache/pulsar#7406 uses a **thread based** publish bytes stats. The other refactors are: 1. Change the throttling related fields from `InternalServerCnx` to `KafkaRequestHandler`. 2. Use `BrokerService#getPausedConnections` to check if the channel's auto read is disabled and modify the tests as well.
@jiazhai PTAL, it looks like the dependency from bintray is not available from now. See another PR's CI: https://github.com/streamnative/kop/pull/495/checks?check_run_id=2568314587
|
### Motivation When there're a lot of topics, there could be a lot of `MetadataCache` instances in memory. ![image](https://user-images.githubusercontent.com/18204803/129903767-4b2f3961-c0e1-4ad5-88b0-7451ed41393a.png) This bug was introduced from #488 because the Pulsar side adopted a new class `MetadataCache` as ZK cache. However, each time `MetadataStore#getMetadataCache` is called, a new `MetadataCache` instance will be created. In KoP, it means that each time a topic lookup is performed, a new `MetadataCache` instance will be created. ### Modifications Only call `MetadataStore#getMetadataCache` once when KoP starts and reuse the same `MetadataCache` instance for each `KafkaRequestHandler` instance.
### Motivation When there're a lot of topics, there could be a lot of `MetadataCache` instances in memory. ![image](https://user-images.githubusercontent.com/18204803/129903767-4b2f3961-c0e1-4ad5-88b0-7451ed41393a.png) This bug was introduced from #488 because the Pulsar side adopted a new class `MetadataCache` as ZK cache. However, each time `MetadataStore#getMetadataCache` is called, a new `MetadataCache` instance will be created. In KoP, it means that each time a topic lookup is performed, a new `MetadataCache` instance will be created. ### Modifications Only call `MetadataStore#getMetadataCache` once when KoP starts and reuse the same `MetadataCache` instance for each `KafkaRequestHandler` instance.
This PR upgrades pulsar dependency to 2.8.0-rc-202105092228, which has two major API changes.
apache/pulsar#10391 changed
LoadManager
API so thatMetadataCache
is used instead ofZookeeperCache
in this PR.apache/pulsar#7406 changed the throttling strategy. However, currently KoP is different from Pulsar that the produce and its callback may be in different threads. KoP calls
PersistentTopic#publishMessages
in a callback ofKafkaTopicManager#getTopic
if the returned future is not completed immediately. Otherwise, it's called just in the I/O thread. Therefore, here we still use a channel based publish bytes stats for throttling, while apache/pulsar#7406 uses a thread based publish bytes stats.The other refactors are:
InternalServerCnx
toKafkaRequestHandler
.BrokerService#getPausedConnections
to check if the channel's auto read is disabled and modify the tests as well.