Jennifer88huang commented on a change in pull request #7756: URL: https://github.com/apache/pulsar/pull/7756#discussion_r472056698
########## File path: site2/website/blog/2020-08-17-Apache-Pulsar-2-6-1.md ########## @@ -0,0 +1,295 @@ +--- +author: XiaoLong Ran +authorURL: https://twitter.com/wolf4j1 +title: Apache Pulsar 2.6.1 +--- +We are very glad to see the Apache Pulsar community has successfully released the wonderful 2.6.1 version after accumulated hard work. It is a great milestone for this fast-growing project and the whole Pulsar community. This is the result of a huge effort from the community, with over 90 commits and a long list of improvements and bug fixes. + +Here is a selection of some of the most interesting and major features added to Pulsar 2.6.1. + +<!--truncate--> + +## Broker + +#### Limit the batch size to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` + +The Batch size is not limited to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` from the `BatchReceive` policy. + +1. Batch size is not limited to the minimum of the maxNumberOfMessages and maxSizeOfMessages from the BatchReceive policy. +2. When the batch size is greater than the receiveQ of the consumer (I used a batch size of 3000 and a receiveQ of 500), I notice the following issues: + + In a multi-topic (pattern) consumer, the client stops receiving any messages. I think it gets paused and never resumed when setting a timeout in the batch policy. Only one batch is fetched and the client is never resumed. + +For more information about implementation details, see [PR-6865](https://github.com/apache/pulsar/pull/6865). + +#### Fix hash range conflict issue in Key_Shared subscription with sticky hash range +In `Key_Shared` subscription where the`stickyHashRange` is used, consumers are not allowed to use interleaving hashes. + +The pull request will fix hash range conflict issue in `Key_Shared` with sticky hash range. Review comment: will fix --> fixes ########## File path: site2/website/blog/2020-08-17-Apache-Pulsar-2-6-1.md ########## @@ -0,0 +1,295 @@ +--- +author: XiaoLong Ran +authorURL: https://twitter.com/wolf4j1 +title: Apache Pulsar 2.6.1 +--- +We are very glad to see the Apache Pulsar community has successfully released the wonderful 2.6.1 version after accumulated hard work. It is a great milestone for this fast-growing project and the whole Pulsar community. This is the result of a huge effort from the community, with over 90 commits and a long list of improvements and bug fixes. + +Here is a selection of some of the most interesting and major features added to Pulsar 2.6.1. + +<!--truncate--> + +## Broker + +#### Limit the batch size to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` + +The Batch size is not limited to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` from the `BatchReceive` policy. + +1. Batch size is not limited to the minimum of the maxNumberOfMessages and maxSizeOfMessages from the BatchReceive policy. +2. When the batch size is greater than the receiveQ of the consumer (I used a batch size of 3000 and a receiveQ of 500), I notice the following issues: Review comment: Take care of the following: 1. Item 1 is identical to the sentence above. 2. It's release blog, could we avoid using "I used ..., I notice....)? ########## File path: site2/website/blog/2020-08-17-Apache-Pulsar-2-6-1.md ########## @@ -0,0 +1,295 @@ +--- +author: XiaoLong Ran +authorURL: https://twitter.com/wolf4j1 +title: Apache Pulsar 2.6.1 +--- +We are very glad to see the Apache Pulsar community has successfully released the wonderful 2.6.1 version after accumulated hard work. It is a great milestone for this fast-growing project and the whole Pulsar community. This is the result of a huge effort from the community, with over 90 commits and a long list of improvements and bug fixes. + +Here is a selection of some of the most interesting and major features added to Pulsar 2.6.1. + +<!--truncate--> + +## Broker + +#### Limit the batch size to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` + +The Batch size is not limited to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` from the `BatchReceive` policy. + +1. Batch size is not limited to the minimum of the maxNumberOfMessages and maxSizeOfMessages from the BatchReceive policy. +2. When the batch size is greater than the receiveQ of the consumer (I used a batch size of 3000 and a receiveQ of 500), I notice the following issues: + + In a multi-topic (pattern) consumer, the client stops receiving any messages. I think it gets paused and never resumed when setting a timeout in the batch policy. Only one batch is fetched and the client is never resumed. Review comment: what does "it" mean in "I think it gets paused..."? ########## File path: site2/website/blog/2020-08-17-Apache-Pulsar-2-6-1.md ########## @@ -0,0 +1,295 @@ +--- +author: XiaoLong Ran +authorURL: https://twitter.com/wolf4j1 +title: Apache Pulsar 2.6.1 +--- +We are very glad to see the Apache Pulsar community has successfully released the wonderful 2.6.1 version after accumulated hard work. It is a great milestone for this fast-growing project and the whole Pulsar community. This is the result of a huge effort from the community, with over 90 commits and a long list of improvements and bug fixes. + +Here is a selection of some of the most interesting and major features added to Pulsar 2.6.1. + +<!--truncate--> + +## Broker + +#### Limit the batch size to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` + +The Batch size is not limited to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` from the `BatchReceive` policy. + +1. Batch size is not limited to the minimum of the maxNumberOfMessages and maxSizeOfMessages from the BatchReceive policy. +2. When the batch size is greater than the receiveQ of the consumer (I used a batch size of 3000 and a receiveQ of 500), I notice the following issues: + + In a multi-topic (pattern) consumer, the client stops receiving any messages. I think it gets paused and never resumed when setting a timeout in the batch policy. Only one batch is fetched and the client is never resumed. + +For more information about implementation details, see [PR-6865](https://github.com/apache/pulsar/pull/6865). + +#### Fix hash range conflict issue in Key_Shared subscription with sticky hash range +In `Key_Shared` subscription where the`stickyHashRange` is used, consumers are not allowed to use interleaving hashes. Review comment: the`stickyHashRange` --> the `stickyHashRange` ########## File path: site2/website/blog/2020-08-17-Apache-Pulsar-2-6-1.md ########## @@ -0,0 +1,295 @@ +--- +author: XiaoLong Ran +authorURL: https://twitter.com/wolf4j1 +title: Apache Pulsar 2.6.1 +--- +We are very glad to see the Apache Pulsar community has successfully released the wonderful 2.6.1 version after accumulated hard work. It is a great milestone for this fast-growing project and the whole Pulsar community. This is the result of a huge effort from the community, with over 90 commits and a long list of improvements and bug fixes. + +Here is a selection of some of the most interesting and major features added to Pulsar 2.6.1. + +<!--truncate--> + +## Broker + +#### Limit the batch size to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` + +The Batch size is not limited to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` from the `BatchReceive` policy. + +1. Batch size is not limited to the minimum of the maxNumberOfMessages and maxSizeOfMessages from the BatchReceive policy. +2. When the batch size is greater than the receiveQ of the consumer (I used a batch size of 3000 and a receiveQ of 500), I notice the following issues: + + In a multi-topic (pattern) consumer, the client stops receiving any messages. I think it gets paused and never resumed when setting a timeout in the batch policy. Only one batch is fetched and the client is never resumed. + +For more information about implementation details, see [PR-6865](https://github.com/apache/pulsar/pull/6865). + +#### Fix hash range conflict issue in Key_Shared subscription with sticky hash range +In `Key_Shared` subscription where the`stickyHashRange` is used, consumers are not allowed to use interleaving hashes. + +The pull request will fix hash range conflict issue in `Key_Shared` with sticky hash range. + +For more information about implementation details, see [PR-7231](https://github.com/apache/pulsar/pull/7231). + +#### Fix: get lookup permission error + +Currently，when Pulsar AuthorizationService checks lookup permission, if the user has the role canProducer **or** canConsumer, it means that the user can perform canLookup operations, but actually in the code: + +```java +try { + return canLookupAsync(topicName, role, authenticationData) + .get(conf.getZooKeeperOperationTimeoutSeconds(), SECONDS); +} +``` +If the method `canProduce` or `canConsume` throw an exception, the `canLookup` method will just throw the exception and will not check the other permission. Review comment: Release notes and blogs describe some objective facts, use present tense, and avoid using "will" if possible. ########## File path: site2/website/blog/2020-08-17-Apache-Pulsar-2-6-1.md ########## @@ -0,0 +1,295 @@ +--- +author: XiaoLong Ran +authorURL: https://twitter.com/wolf4j1 +title: Apache Pulsar 2.6.1 +--- +We are very glad to see the Apache Pulsar community has successfully released the wonderful 2.6.1 version after accumulated hard work. It is a great milestone for this fast-growing project and the whole Pulsar community. This is the result of a huge effort from the community, with over 90 commits and a long list of improvements and bug fixes. + +Here is a selection of some of the most interesting and major features added to Pulsar 2.6.1. + +<!--truncate--> + +## Broker + +#### Limit the batch size to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` + +The Batch size is not limited to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` from the `BatchReceive` policy. + +1. Batch size is not limited to the minimum of the maxNumberOfMessages and maxSizeOfMessages from the BatchReceive policy. +2. When the batch size is greater than the receiveQ of the consumer (I used a batch size of 3000 and a receiveQ of 500), I notice the following issues: Review comment: Suggestion: When the batch size is greater than the `receiveQ` of the consumer (for example, the batch size is 3000 and a receiveQ is 500), the following issue occurs: ########## File path: site2/website/blog/2020-08-17-Apache-Pulsar-2-6-1.md ########## @@ -0,0 +1,295 @@ +--- +author: XiaoLong Ran +authorURL: https://twitter.com/wolf4j1 +title: Apache Pulsar 2.6.1 +--- +We are very glad to see the Apache Pulsar community has successfully released the wonderful 2.6.1 version after accumulated hard work. It is a great milestone for this fast-growing project and the whole Pulsar community. This is the result of a huge effort from the community, with over 90 commits and a long list of improvements and bug fixes. + +Here is a selection of some of the most interesting and major features added to Pulsar 2.6.1. + +<!--truncate--> + +## Broker + +#### Limit the batch size to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` + +The Batch size is not limited to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` from the `BatchReceive` policy. + +1. Batch size is not limited to the minimum of the maxNumberOfMessages and maxSizeOfMessages from the BatchReceive policy. +2. When the batch size is greater than the receiveQ of the consumer (I used a batch size of 3000 and a receiveQ of 500), I notice the following issues: + + In a multi-topic (pattern) consumer, the client stops receiving any messages. I think it gets paused and never resumed when setting a timeout in the batch policy. Only one batch is fetched and the client is never resumed. + +For more information about implementation details, see [PR-6865](https://github.com/apache/pulsar/pull/6865). + +#### Fix hash range conflict issue in Key_Shared subscription with sticky hash range +In `Key_Shared` subscription where the`stickyHashRange` is used, consumers are not allowed to use interleaving hashes. + +The pull request will fix hash range conflict issue in `Key_Shared` with sticky hash range. + +For more information about implementation details, see [PR-7231](https://github.com/apache/pulsar/pull/7231). + +#### Fix: get lookup permission error + +Currently，when Pulsar AuthorizationService checks lookup permission, if the user has the role canProducer **or** canConsumer, it means that the user can perform canLookup operations, but actually in the code: + +```java +try { + return canLookupAsync(topicName, role, authenticationData) + .get(conf.getZooKeeperOperationTimeoutSeconds(), SECONDS); +} +``` +If the method `canProduce` or `canConsume` throw an exception, the `canLookup` method will just throw the exception and will not check the other permission. + +The pull request will invoke `canLookupAsync` instead. + +For more information about implementation details, see [PR-7234](https://github.com/apache/pulsar/pull/7234). + +#### Avoid introducing null read position for the managed cursor + +Avoid introducing null read position for the managed cursor. The most doubtful thing is `getNextValidPosition` method in the `ManagedLedgerImpl`. If a given position is greater than the last add position, it will return a null value. This may cause the read position to become null. But I have not found how this situation appears. So in the PR, I added a log and print the stack trace which can help us to find the root cause and fallback to the next position of the last position if the null next valid position occurs. Review comment: 1. it will return --> it returns 2. Who is "I"? Try to avoid using "I"/"We". Please check other similar cases. ########## File path: site2/website/blog/2020-08-17-Apache-Pulsar-2-6-1.md ########## @@ -0,0 +1,295 @@ +--- +author: XiaoLong Ran +authorURL: https://twitter.com/wolf4j1 +title: Apache Pulsar 2.6.1 +--- +We are very glad to see the Apache Pulsar community has successfully released the wonderful 2.6.1 version after accumulated hard work. It is a great milestone for this fast-growing project and the whole Pulsar community. This is the result of a huge effort from the community, with over 90 commits and a long list of improvements and bug fixes. + +Here is a selection of some of the most interesting and major features added to Pulsar 2.6.1. + +<!--truncate--> + +## Broker + +#### Limit the batch size to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` + +The Batch size is not limited to the minimum of the `maxNumberOfMessages` and `maxSizeOfMessages` from the `BatchReceive` policy. + +1. Batch size is not limited to the minimum of the maxNumberOfMessages and maxSizeOfMessages from the BatchReceive policy. +2. When the batch size is greater than the receiveQ of the consumer (I used a batch size of 3000 and a receiveQ of 500), I notice the following issues: + + In a multi-topic (pattern) consumer, the client stops receiving any messages. I think it gets paused and never resumed when setting a timeout in the batch policy. Only one batch is fetched and the client is never resumed. + +For more information about implementation details, see [PR-6865](https://github.com/apache/pulsar/pull/6865). + +#### Fix hash range conflict issue in Key_Shared subscription with sticky hash range +In `Key_Shared` subscription where the`stickyHashRange` is used, consumers are not allowed to use interleaving hashes. + +The pull request will fix hash range conflict issue in `Key_Shared` with sticky hash range. + +For more information about implementation details, see [PR-7231](https://github.com/apache/pulsar/pull/7231). + +#### Fix: get lookup permission error + +Currently，when Pulsar AuthorizationService checks lookup permission, if the user has the role canProducer **or** canConsumer, it means that the user can perform canLookup operations, but actually in the code: Review comment: I. why do we use bold font for "**or**"? 2. Adopt code font or bold font for the following role/operation/method. `canProducer` or `canConsumer` `canLookup` ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
