-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[improve][pip] PIP-368: Support lookup based on the lookup properties #23075
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@RobertIndie Please add the following content to your PR description and select a checkbox:
|
github-actions
bot
added
doc
Your PR contains doc changes, no matter whether the changes are in markdown or code files.
and removed
doc-label-missing
labels
Jul 25, 2024
RobertIndie
changed the title
[improve][pip] PIP-368: Support client properties for the lookup
[improve][pip] PIP-368: Support lookup based on the lookup properties
Jul 30, 2024
liangyepianzhou
approved these changes
Aug 5, 2024
Demogorgon314
approved these changes
Aug 7, 2024
The vote has passed with 3 binding +1s. https://lists.apache.org/thread/z0t3dyqj27ldm8rs6nl5jon152ohghvw |
Denovo1998
pushed a commit
to Denovo1998/pulsar
that referenced
this pull request
Aug 17, 2024
…apache#23075) ### Motivation Currently, the lookup process uses only the topic name as its parameter. However, to enhance this process, it's beneficial for clients to provide additional information. This could be done by introducing the `lookupProperties` field in the client configuration. Clients can then share these properties with the broker during lookup. On the broker side, the broker could also contain some properties that are used for the lookup. We can also support the lookupProperties for the broker. The broker can use these properties to make a better decision on which broker to return. Here is the rack-aware lookup scenario for using the client properties for the lookup: Assuming there are two brokers that broker-0 configures the lookup property "rack" with "A" and broker-1 configures the lookup property "rack" with "B". By using the lookup properties, clients can supply rack information during the lookup, enabling the broker to identify and connect them to the nearest broker within the same rack. If a client that configures the "rack" property with "A" connects to a lookup broker, the customized load manager can determine broker-0 as the owner broker since the broker and the client have the same rack property. ### Modifications Add new configuration `lookupProperties` to the client. While looking up the broker, the client will send the properties to the broker through `CommandLookupTopic` request. The `lookupProperties` will then be added to the `LookupOptions`. The Load Manager implementation can access the `properties` through `LookupOptions` to make a better decision on which broker to return. The properties are used only when the protocol is the binary protocol, starting with `pulsar://` or `pulsar+ssl://`, or if the `loadManagerClassName` in the broker is a class that implements the `ExtensibleLoadManager` interface. To support configuring the `lookupProperties` on the broker side, introduce a new broker configuration `lookupPropertyPrefix`. Any broker configuration properties that start with the `lookupPropertyPrefix` will be included into the `BrokerLookupData` and be persisted in the metadata store. The broker can use these properties during the lookup. In this way, to support the rack-aware lookup scenario mentioned in the "Motivation" part, the client can set the rack information in the client `lookupProperties`. Similarly, the broker can also set the rack information in the broker configuration like `lookup.rack`. The `lookup.rack` will be stored in the `BrokerLookupData`. A customized load manager can then be implemented. For each lookup request, it will go through the `BrokerLookupData` for all brokers and select the broker in the same rack to return.
15 tasks
RobertIndie
added a commit
that referenced
this pull request
Aug 28, 2024
…#23223) PIP: #23075 ### Motivation This is the implementation for the PIP: #23075 Currently, the lookup process uses only the topic name as its parameter. However, to enhance this process, it's beneficial for clients to provide additional information. This could be done by introducing the `lookupProperties` field in the client configuration. Clients can then share these properties with the broker during lookup. On the broker side, the broker could also contain some properties that are used for the lookup. We can also support the lookupProperties for the broker. The broker can use these properties to make a better decision on which broker to return. Here is the rack-aware lookup scenario for using the client properties for the lookup: Assuming there are two brokers that broker-0 configures the lookup property "rack" with "A" and broker-1 configures the lookup property "rack" with "B". By using the lookup properties, clients can supply rack information during the lookup, enabling the broker to identify and connect them to the nearest broker within the same rack. If a client that configures the "rack" property with "A" connects to a lookup broker, the customized load manager can determine broker-0 as the owner broker since the broker and the client have the same rack property. ### Modifications - Add new configuration `lookupProperties` to the client. While looking up the broker, the client will send the properties to the broker through `CommandLookupTopic` request. - Add `properties` field to the `CommandLookupTopic`. - Add `lookupProperties` to the `LookupOptions`. The Load Manager implementation can access the `properties` through `LookupOptions` to make a better decision on which broker to return. - Introduce a new broker configuration `lookupPropertyPrefix`. Any broker configuration properties that start with the `lookupPropertyPrefix` will be included into the `BrokerLookupData` and be persisted in the metadata store. The broker can use these properties during the lookup. Co-authored-by: Yunze Xu <xyzinfernity@163.com>
grssam
pushed a commit
to grssam/pulsar
that referenced
this pull request
Sep 4, 2024
…apache#23075) ### Motivation Currently, the lookup process uses only the topic name as its parameter. However, to enhance this process, it's beneficial for clients to provide additional information. This could be done by introducing the `lookupProperties` field in the client configuration. Clients can then share these properties with the broker during lookup. On the broker side, the broker could also contain some properties that are used for the lookup. We can also support the lookupProperties for the broker. The broker can use these properties to make a better decision on which broker to return. Here is the rack-aware lookup scenario for using the client properties for the lookup: Assuming there are two brokers that broker-0 configures the lookup property "rack" with "A" and broker-1 configures the lookup property "rack" with "B". By using the lookup properties, clients can supply rack information during the lookup, enabling the broker to identify and connect them to the nearest broker within the same rack. If a client that configures the "rack" property with "A" connects to a lookup broker, the customized load manager can determine broker-0 as the owner broker since the broker and the client have the same rack property. ### Modifications Add new configuration `lookupProperties` to the client. While looking up the broker, the client will send the properties to the broker through `CommandLookupTopic` request. The `lookupProperties` will then be added to the `LookupOptions`. The Load Manager implementation can access the `properties` through `LookupOptions` to make a better decision on which broker to return. The properties are used only when the protocol is the binary protocol, starting with `pulsar://` or `pulsar+ssl://`, or if the `loadManagerClassName` in the broker is a class that implements the `ExtensibleLoadManager` interface. To support configuring the `lookupProperties` on the broker side, introduce a new broker configuration `lookupPropertyPrefix`. Any broker configuration properties that start with the `lookupPropertyPrefix` will be included into the `BrokerLookupData` and be persisted in the metadata store. The broker can use these properties during the lookup. In this way, to support the rack-aware lookup scenario mentioned in the "Motivation" part, the client can set the rack information in the client `lookupProperties`. Similarly, the broker can also set the rack information in the broker configuration like `lookup.rack`. The `lookup.rack` will be stored in the `BrokerLookupData`. A customized load manager can then be implemented. For each lookup request, it will go through the `BrokerLookupData` for all brokers and select the broker in the same rack to return.
grssam
pushed a commit
to grssam/pulsar
that referenced
this pull request
Sep 4, 2024
…apache#23223) PIP: apache#23075 ### Motivation This is the implementation for the PIP: apache#23075 Currently, the lookup process uses only the topic name as its parameter. However, to enhance this process, it's beneficial for clients to provide additional information. This could be done by introducing the `lookupProperties` field in the client configuration. Clients can then share these properties with the broker during lookup. On the broker side, the broker could also contain some properties that are used for the lookup. We can also support the lookupProperties for the broker. The broker can use these properties to make a better decision on which broker to return. Here is the rack-aware lookup scenario for using the client properties for the lookup: Assuming there are two brokers that broker-0 configures the lookup property "rack" with "A" and broker-1 configures the lookup property "rack" with "B". By using the lookup properties, clients can supply rack information during the lookup, enabling the broker to identify and connect them to the nearest broker within the same rack. If a client that configures the "rack" property with "A" connects to a lookup broker, the customized load manager can determine broker-0 as the owner broker since the broker and the client have the same rack property. ### Modifications - Add new configuration `lookupProperties` to the client. While looking up the broker, the client will send the properties to the broker through `CommandLookupTopic` request. - Add `properties` field to the `CommandLookupTopic`. - Add `lookupProperties` to the `LookupOptions`. The Load Manager implementation can access the `properties` through `LookupOptions` to make a better decision on which broker to return. - Introduce a new broker configuration `lookupPropertyPrefix`. Any broker configuration properties that start with the `lookupPropertyPrefix` will be included into the `BrokerLookupData` and be persisted in the metadata store. The broker can use these properties during the lookup. Co-authored-by: Yunze Xu <xyzinfernity@163.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Currently, the lookup process uses only the topic name as its parameter. However, to enhance this process, it's
beneficial for clients to provide additional information. This could be done by introducing the
lookupProperties
fieldin the client configuration. Clients can then share these properties with the broker during lookup.
On the broker side, the broker could also contain some properties that are used for the lookup. We can also support the
lookupProperties for the broker. The broker can use these properties to make a better decision on which broker to
return.
Here is the rack-aware lookup scenario for using the client properties for the lookup:
Assuming there are two brokers that broker-0 configures the lookup property "rack" with "A" and broker-1 configures the
lookup property "rack" with "B". By using the lookup properties, clients can supply rack information during the lookup,
enabling the broker to identify and connect them to the nearest broker within the same rack. If a client that configures
the "rack" property with "A" connects to a lookup broker, the customized load manager can determine broker-0 as the
owner broker since the broker and the client have the same rack property.
Modifications
Add new configuration
lookupProperties
to the client. While looking up the broker, the client will send the propertiesto the broker through
CommandLookupTopic
request.The
lookupProperties
will then be added to theLookupOptions
. The Load Manager implementation can accessthe
properties
throughLookupOptions
to make a better decision on which broker to return.The properties are used only when the protocol is the binary protocol, starting with
pulsar://
orpulsar+ssl://
, orif the
loadManagerClassName
in the broker is a class that implements theExtensibleLoadManager
interface.To support configuring the
lookupProperties
on the broker side, introduce a new brokerconfiguration
lookupPropertyPrefix
. Any broker configuration properties that start with thelookupPropertyPrefix
will be included into the
BrokerLookupData
and be persisted in the metadata store. The broker can use these propertiesduring the lookup.
In this way, to support the rack-aware lookup scenario mentioned in the "Motivation" part, the client can set the rack
information in the client
lookupProperties
. Similarly, the broker can also set the rack information in the brokerconfiguration like
lookup.rack
. Thelookup.rack
will be stored in theBrokerLookupData
. A customized load managercan then be implemented. For each lookup request, it will go through the
BrokerLookupData
for all brokers and selectthe broker in the same rack to return.
Does this pull request potentially affect one of the following parts:
If the box was checked, please highlight the changes
Documentation
doc
doc-required
doc-not-needed
doc-complete
Matching PR in forked repository
PR in forked repository: