Hi, Qiang > It is necessary to check the current cursor status when handling flowPermits > request from the server side. If the server is handling seek request, it > should ignore flowPermits request because the request is illegal.
Thanks for your explanation. I think it's better to add this explanation to the PIP. > The reconnected consumer can regard as a new consumer with new epoch. The consumer will reconnect to the broker during the seek operation. And this will change the existing behavior. It doesn't seem to make sense. Please correct me if I have misunderstood. Thanks, Zike Yang On Wed, Jul 27, 2022 at 8:06 PM Qiang Huang <qiang.huang1...@gmail.com> wrote: > > Thanks Zike. > > > - stage 1: Check the current cursor status when handling flowPermits > from > > > the server side. > > > > Could you explain more details on this step? It looks like there is > not much described above. What kind of status needs to be checked, and > what kind of behavior will the broker take? > It is necessary to check the current cursor status when handling flowPermits > request from the server side. If the server is handling seek request, it > should ignore flowPermits request because the request is illegal. > > > > > 1. Consumer reconnect need reset epoch. > >> Why do we need to reset the epoch when the consumer reconnects? > The reconnected consumer can regard as a new consumer with new epoch.
