--
Matteo Merli
<matteo.me...@gmail.com>
On Tue, Aug 8, 2023 at 9:56 PM Michael Marshall <mmarsh...@apache.org>
wrote:
> Thanks for your proposal, Heesung. Sorry for my late response. Just
> want to make a few points to hopefully improve the implementation.
> Overall, I think this feature is absolutely the right direction for
> Pulsar and will be a great improvement. I remember discussing this at
> some community meetings last year. See the last paragraph of [0].
>
> In general, my primary question is about the protocol changes you're
> proposing, both the commands and the way the commands are sent.
>
> > I am worried about the backward compatibility if we add a new proto
> message
> > -- how can the old versions of clients handle this new proto message?
>
> The protocolVersion [1] object in the proto definition is how we
> guarantee backwards and forwards compatibility for all combinations of
> brokers/clients. The client and the broker each share their version
> during the handshake and then they only use commands known to both
> peers.
> We can introduce a new command here if we want/need. The nuance is
> that the server logic will branch depending on the client's
> protocolVersion.
>
> I don't see versioning the protocol as a negative as long as there is
> sufficient benefit. In this case, the new command serves an explicit
> purpose to make the protocol more reactive (the client knows what is
> happening as it happens without any need to poll) and less wasteful
> (no unnecessary data transfer).
>
> One reason I want to push on this design is because I think it will be
> harder to change once it is in place. Adding the new broker URL to the
> close producer and close consumer commands necessarily couples the
> events. Using separate commands allows them to be decoupled, and in my
> opinion, that matches the reality of the problem. We know we want to
> close the producer/consumer before we know where they should connect
> next.
Indeed adding a new command is a possibility, and the protocol has the
option to have feature flags so that each side can understand whether a
feature is supported by the other side.
My view here is that having a mechanism to notify the producers to pause
sending messages has only a very little benefit and multiple drawbacks.
Benefit: if we tell the producer to pause sending (while the topic is
moved), we would spare some network traffic (producer -> broker)
Drawbacks:
1. Brokers need to be able to handle both cases
a. Send a pause-producer command and ignore any in-inflight messages
b. If the producer does not support this feature, the broker would
have to ignore messages anyway
2. This change would create multiple complications in the clients
implementations:
a. A new state to take care of
b. What to do with the pending messages, eg: manage and addition
pending messages queue
3. What to do with consumers (eg: broker would still have to ignore the
acks while the topic is closing)
I don't see the sparing of network traffic during the failover as a huge
benefit that justifies the added complexity in broker & client libraries.
In both cases, once the topic is recovered in the new broker, all the same
pending messages will have to be resent to the broker and the same
bandwidth will be used there.
All in all, I don't see the close-producer and redirect as two separate
operations.The close is piggy-backing the information to skip the service
discovery. If the clients supports it, it will make use of it, otherwise
fall back to current behavior and do a lookup.
