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, the 
redeliverUnacknowledgedMessages method should be synchronous, maybe we can 
modify it to be synchronous and support retrying.



Thanks,
Baodi Shi

> 2022年11月21日 21:03,丛搏 <congbobo...@gmail.com> 写道:
> 
> 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`:
> https://github.com/apache/pulsar/blob/master/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ConsumerImpl.java#L1907-L1909
> 
> `MultiTopicsConsumerImpl`:
> https://github.com/apache/pulsar/blob/master/pulsar-client/src/main/java/org/apache/pulsar/client/impl/MultiTopicsConsumerImpl.java#L667-L677
> 
> in the shared subType, I think it doesn't need the response of the
> `void redeliverUnacknowledgedMessages()`, and naming the
> `redeliverUnacknowledgedMessages` is ok.
> 
> but in failover and exclusive subType, if we don't get the response,
> the user will receive the message from the `incomingQueue` then the
> order of the message will be broken.  If the
> `redeliverUnacknowledgedMessages` timeout, we should try again. but
> `redeliverUnacknowledgedMessages` doesn't throw any exception or
> retry. and the `redeliverUnacknowledgedMessages` name is not accurate
> for failover and exclusive subType. it is named `rewind` is more
> suitable.
> 
> So I suggest `redeliverUnacknowledgedMessages` be deprecated under
> failover and exclusive subType and add a new similar async and sync
> method called `rewind` for failover and exclusive subType.
> 
> Please leave your comments or suggestions, thanks!
> 
> Thanks,
> bo

Reply via email to