+1
Regards
Jiwei Guo (Tboy)
On Tue, Mar 21, 2023 at 4:21 PM Zike Yang wrote:
>
> > To keep the goal clear, we can only set `httpClientRequestBufferSize`
> internally without giving the user a way to change it.
>
> +1.
>
> Thanks,
> Zike Yang
>
> On Tue, Mar 21, 2023 at 4:08 PM Yubiao Feng
>
I am not following your objections to the protocol solution. It might
be more productive if I provided a draft PR with a sample
implementation. I'm not sure that I'll have time, but I'll try to put
something together this week.
> At least it will simplify the process of using cumulative ack with
Hi, Michael
> In this case, the consumer does not have the source of truth for the
> readPosition. It would leave the new protocol field for `readPosition`
> empty and the broker would use its source of truth for the read
> position.
application has received all the messages by application thread.
Hi, Yunze:
It is true that hiding these details in the SDK still requires users to have a
certain level of understanding of the configuration. However, this approach
can still be helpful for users who want to use the feature but want
to avoid dealing with the nitty-gritty details of
Good questions. There were some gaps in my description above.
> I think it is the[0], when the `incomingMessages` queue is empty,
> how do we get the correct `startPosition`?
In this case, the consumer does not have the source of truth for the
readPosition. It would leave the new protocol field
I just missed the point that the reset cursor operations do not work
for the consumer. IIUC, the seek operation does not work as well. Then
I think the option is not user-friendly as the PIP says:
> It needs to be enabled with a complete understanding of this configuration.
If users want, they
Hi, Michael:
Michael Marshall 于2023年3月21日周二 23:17写道：
>
> One more point. Instead of keeping track of the latest message seen by
> the application, the logic in my solution would actually just check
> the last message in the `incomingMessages` queue (as in the most
> recently added), and use
> This appears to be the "round-robin topic-to-bundle mapping" option in
> the `fundBundle` function. Is this the only place that needs an update? Can
> you list what change is required?
In this PIP, we only discuss topic-to-bundle mapping
Change is required:
1)
When lookup, partitions is
The namespace level bundle-unload can be performed in
NamespaceService#splitAndOwnBundleOnceAndRetry
A new judgment will be added here.
After splitting the bundle, it should determine whether to unload at the
namespace level.
On 2023/03/19 09:53:07 lifepuzzlefun wrote:
> I'm interest on the
Hi, I see. I have follow-up questions below.
- This appears to be the "round-robin topic-to-bundle mapping" option in
the `fundBundle` function. Is this the only place that needs an update? Can
you list what change is required?
- How do we enable this "round-robin topic-to-bundle mapping option"
One more point. Instead of keeping track of the latest message seen by
the application, the logic in my solution would actually just check
the last message in the `incomingMessages` queue (as in the most
recently added), and use that as the read position in the subscribe
command. If we made this
> if we add the new field in CommandSubscribe, we should ensure
> the synchronization between consumer reconnection and user
> calling receive and redeliverUnack method. it will affect the performance
> of receive. expose synchronization to hot paths it not a good idea.
I don't think this is a
Thanks for joining this discussion
> 1. where is the partition to bundle mapping stored？
We don't need to store the mapping relationship, it can be calculated
dynamically. The first is the starting bundle, partition-0 is calculated
directly through consistent hashing. Subsequent partitions
+1
Hi, Bo :
Thanks for your explanation. That makes sense to me.
Thanks,
Yubiao Feng
On Mon, Mar 20, 2023 at 10:21 PM 丛搏 wrote:
> Hi, pulsar community:
>
> I started a PIP about `Client consumer filter received messages`.
>
> PIP: https://github.com/apache/pulsar/issues/19864
>
> Thanks,
>
Hi, Aloys:
Yes, it will work with `consumer.seek()`.
Sorry, I missed this, I will add this description to the PIP.
But the current seek method has some problems, the detail in
https://lists.apache.org/thread/97o9t4ltkds5pfq41l9xbbd31t41qm8w,
I am not sure, does it make sense to support seek
Hi, Yunze:
Yunze Xu 于2023年3月21日周二 17:19写道：
>
>
> Is there any breaking change if we just apply this filter without
> adding a configuration option?
If not add this configuration, the Pulsar Admin reset cursor will cause
the wrong behavior. It will filter the messages which have been reset.
As
Here is my voting thread:
https://lists.apache.org/thread/ph25f3p405ky78w91r08hd8f0jmkdwh0
Thanks!
> On 21 Mar 2023, at 1:47, tison wrote:
>
> FWIW - Anyone can request edit permission on ASF Confluence space, but the
> wiki page permission is more tricky, and it's more unfriendly for
I make a patch for adding a canonical link in the head metadata:
https://github.com/apache/pulsar-site/pull/481
Welcome to leave a comment.
Best,
tison.
Jun Ma 于2023年3月15日周三 17:11写道：
> Hi, everyone,
>
> When researching tagging metadata to Pulsar docs for SEO, I found this
> issue that
> we
Nice proposal.
I'm interested in a point
> So when we need to reset the cursor, the client consumer should all be
closed, and then reset the cursor then restart the consumer.
Does this requirement apply to `consumer.seek`?
Because in some scenarios, we need to create consumers first and then
For example
https://github.com/apache/pulsar/actions/runs/4454158774/jobs/7867745340?pr=19842
I'm wondering if anyone cares about the report and if it helps you during
the coding or reviewing process? Now it generates a few of noise but I just
omit the report it gives ;-)
For the issue itself,
First, I agree with Yubiao that we can avoid calling the `isDuplicate`
method once this option is enabled.
Then, I'm wondering in which case would users want to disable this
option? What's the disadvantage to disable the option? I think we can
just record the latest position (ledger id, entry id,
> To keep the goal clear, we can only set `httpClientRequestBufferSize`
internally without giving the user a way to change it.
+1.
Thanks,
Zike Yang
On Tue, Mar 21, 2023 at 4:08 PM Yubiao Feng
wrote:
>
> Hi Zike
>
> > Thanks for your explanation. So from my understanding, there are
> >
Based on the private discussion with Yubiao, here is the current update:
Currently, we can get the init parameter `requestBufferSize ` from the
ServletConfig. We need to investigate this configuring method to avoid
the potential conflict issue. And we may not need to expose
+1 (binding)
Thanks,
Yunze
On Tue, Mar 21, 2023 at 2:59 PM 丛搏 wrote:
>
> +1 (binding)
>
> Thanks,
> Bo
>
> Yubiao Feng 于2023年3月20日周一 17:11写道：
> >
> > Hi Pulsar Community
> >
> > This thread is to start the vote for PIP 259.
> >
> > Discussion:
+1 (binding)
Thanks,
Bo
Yubiao Feng 于2023年3月20日周一 17:11写道：
>
> Hi Pulsar Community
>
> This thread is to start the vote for PIP 259.
>
> Discussion: https://lists.apache.org/thread/f11cld5cbc8sodhgvs5s28lw8nxsr9dc
> Issue: https://github.com/apache/pulsar/issues/19826
> Implementation:
Hi Zike
> Exposing `httpClientRequestBufferSize` to help users improve the
> forwarding performance.
It's just an added benefit.
The primary goal is to solve the long HTTP URL.
Since Pulsar Proxy forwards the request to Pulsar Server, it will throw
BufferOverflowException if the length of the
Hi, Michael
Michael Marshall 于2023年3月21日周二 13:03写道：
>
> This is a great problem to improve.
>
> What if we instead expand the CommandSubscribe [0] protocol message
> with a new field to represent the client's desired read position? This
> way, the client can tell the second broker where to start
27 matches
Mail list logo
