Skip to content

Conversation

@codelipenghui
Copy link
Contributor

fix https://github.com/streamnative/pulsar/issues/1723

Motivation

The current policy to control the size of the message is at the broker level(maxMessageSize). It becomes easier to plan resource quotas for client allocation if the max message size pushed can be given at the topic level.

Modifications

Now the broker-level maxMessageSize is returned by the broker to the client, when the broker handles handleConnected. The client will cached maxMessageSize locally. An exception will be thrown if it exceeds the limit.

Topic-level cannot be implemented like this, because:

  1. When handleConnected, the command received by the broker does not contain specific topic information, so it is not known which topic policy to return to the client.
  2. The client cannot cache topic-level policy. Unlike the broker-level policy, which will not change, the topic-level policy will change dynamically, which will involve cache consistency issues.

I think the best way to handle this is to let the broker determine whether it exceeds the limit, and return an exception if it exceeds the limit, and handle the exception by the client's handleSendError.

Verifying this change

TopicPoliciesTest.java

(cherry picked from commit 9c28378)

fix https://github.com/streamnative/pulsar/issues/1723

### Motivation
The current policy to control the size of the message is at the broker level(maxMessageSize). It becomes easier to plan resource quotas for client allocation if the max message size pushed can be given at the topic level.

### Modifications

Now the broker-level `maxMessageSize` is returned by the broker to the client, when the broker handles `handleConnected`. The client will cached `maxMessageSize` locally. An exception will be thrown if it exceeds the limit.

Topic-level cannot be implemented like this, because:
1) When `handleConnected`, the command received by the broker does not contain specific topic information, so it is not known which topic policy to return to the client.
2) The client cannot cache topic-level policy. Unlike the broker-level policy, which will not change, the topic-level policy will change dynamically, which will involve cache consistency issues.

I think the best way to handle this is to let the broker determine whether it exceeds the limit, and return an exception if it exceeds the limit, and handle the exception by the client's `handleSendError`.

### Verifying this change
TopicPoliciesTest.java

(cherry picked from commit 9c28378)
@codelipenghui codelipenghui merged commit addaac7 into branch-2.7 Dec 2, 2020
@codelipenghui
Copy link
Contributor Author

Hey. If you want to cherry-pick this pr to a target branch, please comments '/pulsarbot cherry-pick to branch-x.y'.

@codelipenghui codelipenghui deleted the pulsarbot/cherry-pick-8732 branch May 19, 2021 05:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants