Hello Rajan,
I haven't updated the PIP with a better interface for PublishRateLimiter
yet as the discussion here in this thread went in a different direction.
Personally, I agree with you that even if we choose one algorithm and
improve the built-in rate limiter, it still may not suit all use case
Hi Rajan,
Thank you for sharing your opinion. It appears you are in favor of
pluggable interfaces for rate limiters. I would like to offer a
perspective on why we should defer the pluggability aspect of rate
limiters. If there is a real need, it can be considered later.
Currently, there's a press
Hi Girish,
> On Asaf's comment on too many public interfaces in Pulsar and no other
> Apache software having so many public interfaces - I would like to ask, has
> that brought in any con though? For this particular use case, I feel like
> having it has a public interface would actually improve th
Hello Lari, while I am yet to reply to your yesterday''s email, I am trying
to wrap this discussion about the need of pluggable rate limiter, so
replying to this first.
Comments inline
On Wed, Nov 8, 2023 at 5:35 PM Lari Hotari wrote:
> Hi Girish,
>
> > On Asaf's comment on too many public int
Hi dev,
I proposed a PIP: https://github.com/apache/pulsar/pull/21507 to create a
producerName for DeadLetterPolicy.
Please take a look and give your feedback.
--
Best Regards！
crossoverJie
Hi all
Sorry, I'll send another email explaining what tests were done.
Please ignore the previous email.
Thanks
Yubiao Feng
On Wed, Nov 8, 2023 at 11:48 AM Yubiao Feng
wrote:
> +1 (no-binding)
>
> Thanks
> Yubiao Feng
>
> On Tue, Nov 7, 2023 at 3:03 PM Yunze Xu wrote:
>
>> This is the secon
Hi Yunze,
I got an error when running the pulsar-tests (I tried multiple times, same
error)
```
2023-11-08 22:56:43.676 INFO [0x16db63000] ProducerImpl:216 |
[persistent://public/default/testPartitionedConsumerUnexpectedAckTimeout1699455403-partition-1,
] Created producer on broker [[::1]:58479
I think it's caused by the ClientTest.testConnectTimeout. The
resources seem not cleaned well in this test so it affected the tests
later. Could you try the following command that ignores this test?
```bash
./pulsar-tests --gtest_filter='-ClientTest.testConnectTimeout'
```
If the rest of the tes
Hi everyone! I think that Pulsar deserves an article on Wikipedia.
The problem is that it’s surprisingly hard to find something in-depth,
reliable, secondary, and independent on the subject.
Most of the good information is in Pulsar documentation, StreamNative blog,
DataStax blog, Apache Foundat
Hello Lari,
I've now gone through a bunch of rate limiting algorithms, along with dual
rate, dual bucket algorithm.
Reply inline.
On Tue, Nov 7, 2023 at 11:32 PM Lari Hotari wrote:
>
> Bucket4J documentation gives some good ideas and it's shows how the
> token bucket algorithm could be varied. F
Hi Girish,
Replies inline.
> > The current state of rate limiting is not acceptable in Pulsar. We
> > need to fix things in the core.
> >
>
> I wouldn't say that it's not acceptable. The precise one works as expected
> as a basic rate limiter. Its only when there are complex requirements, the
> c
Hi Yunze,
Thanks for the reminder. I enabled the proxy on my laptop.
After disabling the proxy, the timeout issue is gone.
Now, all the tests get passed except two consistently failed tests related
to the token test.
I have created a GitHub issue.
https://github.com/apache/pulsar-client-cpp/iss
Hi Girish,
replies inline.
On Thu, 9 Nov 2023 at 00:29, Girish Sharma wrote:
> While dual-rate dual token bucket looks promising, there is still some
> challenge with respect to allowing a certain peak burst for/up to a bigger
> duration. I am explaining it below:
> Assume a 10MBps topic. Burst
Hi Penghui,
It's caused by the relative path and I explained it that issue. Here
is an improvement for tests:
https://github.com/apache/pulsar-client-cpp/pull/340.
Thanks,
Yunze
Hi Enrico,
I don't think they conflict. We can do them separately.
We can add the policy to the per topic and per namespace again when we need it
in the future, and the current PIP can just add a configuration to broker.conf
first so that we can not retain the null-key messages and cherry-pick
15 matches
Mail list logo
