[improve][broker]PIP-333 Add monitor metrics for the number of connections to client IPs and roles
Hi everyone,I have an optimization proposal. [improve][broker]PIP-333 Add monitor metrics for the number of connections to client IPs and roles PIP-333:https://github.com/apache/pulsar/pull/21935 Thank you for your help.
[VOTE] Pulsar Client Go Release 0.12.0 Candidate 3
Hi everyone, Please review and vote on the release candidate #3 for the version 0.12.0, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) This is the third release candidate for Apache Pulsar Go client, version 0.12.0. The release note/changelog for Go client 0.12.0: https://github.com/apache/pulsar-client-go/pull/1153/files Pulsar Client Go's KEYS file contains PGP keys we used to sign this release: https://downloads.apache.org/pulsar/KEYS Please download these packages and review this release candidate: - Review release notes: https://github.com/apache/pulsar-client-go/pull/1153 - Download the source package (verify shasum, and asc) and follow the README.md to build and run the pulsar-client-go. The vote will be open for at least 72 hours. It is adopted by majority approval, with at least 3 PMC affirmative votes. Source file: https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.12.0-candidate-3/ The tag to be voted upon: v0.12.0-candidate-3 https://github.com/apache/pulsar-client-go/tree/v0.12.0-candidate-3 SHA-512 checksums: 66c37c4439549a02d7e3d21ecc02c4a2f44bad2232fbf15fb04c42f02fc4caad758b7a1b1663d0df47414af99daa4e3a19d33c29c0decbc43ac4d17e46a126bc apache-pulsar-client-go-0.12.0-src.tar.gz
Re: Ability to decrease partition count in pulsar
Bumping this up! Hoping this can be discussed so that I get rule out that this approach has any fatal flaws. Regards On Fri, Jan 19, 2024 at 11:58 AM Girish Sharma wrote: > Hello everyone, > > A a true cloud native platform, which supports scale up and scale down, I > feel like there is a need to be able to reduce partition count in pulsar to > truly achieve a scale down after events like sales (akin to black friday, > etc) or huge temporary publish burst due to backfill. > > I looked through the archives (upto 2021) and did not find any prior > discussion on the same topic. > > I have given this an initial thought to figure out what would it need to > support such a feature in the lowest footprint possible. I am attaching the > document explaining the need, requirements and initial high level details > [0]. What I would like is to understand if the community also finds this > feature helpful and does the approach described in the document have some > fatal flaw? Summarizing the approach here as well: > >- Introduce an ability to convert a normal topic object into a >read-only topic via admin api and an additional partitioned-topic metadata >property (just like shadow source, etc) >- Add logic to block produce but allow new consumers and dispatch call >based on this flag >- Add logic in GC to clean out read only topics when all of their >ledgers expire (TTL/retention) > > Goal is that there is no data movement involved and no impact on existing > partitions during this scale down. > > Looking forward to the discussion. > > [0] > https://docs.google.com/document/d/1sbGQSwDihQftIRsxAXg5Zm4uxKQ0kRk9HadKYRFTswI/edit?usp=sharing > > Regards > -- > Girish Sharma > -- Girish Sharma
