Hi, Baodi,
>Alternatively, can it be understood that when a user wants to process messages
>in an orderly manner, he cannot call the ‘reconumserLater` and
>'negativeAcknowledge' >methods?
Yes, I think so. This is what the user needs to think about. We need
to provide use cases, and notes for
Hi, Congbo:
> In the above two solutions, it can keep messages in order. but in the
> first solution, we don't know how many messages the user process and
> then cumulative once. If the message numbers are 1000, maybe the
> user can't store the message in the memory for reprocessing. so
Hi, Asaf, Baodi:
I'm very sorry for my late reply. Thanks for your discussion.
> - receive() - get the following message
> - cumulativeAck(msgId) - acknowledge all messages up to msgId.
> - Maybe we can try to come up with a self-explanatory name like
> ackAllUpTo(msgId).
If the user
Hi Baodi,
Yes, in effect, I suggest that we have new Consumer interfaces, one per
subscription type perhaps then we can “correct” the current interface
without breaking backward compatibility.
For Exclusive/Failover, since the idea in those subscription types was to
maintain order, it makes
Hi, Asaf:
Thank you for the comprehensive summary.
> So in effect, what you would have expected here is that nack(4) in
> exclusive/shared will happen immediately - clear queue, write redeliver
> command to broker async and return immediately, hence next receive() will
> block until messages
Ok, I'll try to summarize what I read here to make sure we're all on the
same page :)
Exclusive and Failover subscription types are subscriptions that guarantee
two things:
1. Single active consumer per topic (partition).
2. Message processing in the order they were written to the
topic
Hi, Joe:
> This "brokenness" is not clear to me.
https://github.com/apache/pulsar/pull/10478 This PIP solves some
problems of "brokenness",
>The sequence 3,4,5,6,7,8,9,10,11 12,13,14,15, 16 ,9,10,11,12,13,14,15,16,17,
>18, 19, 20 ...does not break
> the ordering guarantees of Pulsar
If don't use
Hi, Baodi
> After, when the user calls `redeliverUnacknowledgedMessages` under failover
> and exclusive subType,
> It gets a warning reminder that the messages may be out of order, right?
>
yes, in failover and exclusive subType, we should suggest user to use
a new API to redeliver the messages
I am not familiar with all the changes since it's original implementation,
nor can I speak to for all the changes that went after
The original concept was simple and rigorous. For shared sub, all unacked
messages will be redelivered, and for Exclusive subs, the cursor was
rewound and everything
Hi, Bo
Thanks for starting the discussion.
I have no idea about the initial motivation for supporting message
redelivery for
Failover or Exclusive subscription. The redelivered messages will go to the
same
consumer under a single active consumer subscription mode.
Or maybe it is only designed
Hi Congbo
I think it is a goog idea.
Thanks
Yubiao
Yu
On Mon, Nov 21, 2022 at 9:04 PM 丛搏 wrote:
> Hello, Pulsar community:
>
> Now client consumer `void redeliverUnacknowledgedMessages();` is an
> async interface, but it doesn't have the return value. only
> `writeAndFlush` the redeliver
Hi, Congbo:
Thanks for your explanation. I agree to add a new interface for failover and
exclusive subType.
>>> I suggest `redeliverUnacknowledgedMessages` be deprecated under
>>> failover and exclusive subType and add a new similar async and sync
>>> method called `rewind` for failover and
Hi, Baodi:
I don't think it will confuse users, eg. individual ack and cumulative
ack, in the share subType cumulative ack have no use.
because we have individualAck and cumulativeAck, we should have
different redeliver methods for them.
I think adding new methods makes sense unless we separate
Hi, Congbo.
The subscription type is an internal property of the consumer; If two APIs are
provided: redeliverUnacknowledgedMessages(only work on shard) and rewind(only
work exclusive and failover), This can be confusing for users.
Back to the issue, depending on the current usage scenario,
Hello, Pulsar community:
Now client consumer `void redeliverUnacknowledgedMessages();` is an
async interface, but it doesn't have the return value. only
`writeAndFlush` the redeliver command then finishes.
`ConsumerImpl`:
15 matches
Mail list logo
