michaeljmarshall commented on issue #13342: URL: https://github.com/apache/pulsar/issues/13342#issuecomment-1145135003
Just want to post the explicit requirements that must be met for a producer to reconnect. Here is the producer logic: https://github.com/apache/pulsar/blob/7d2fdea7749d72b58def4045be3f295e0ee4f04d/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/Producer.java#L175-L181 and here is where it's called: https://github.com/apache/pulsar/blob/7d2fdea7749d72b58def4045be3f295e0ee4f04d/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/AbstractTopic.java#L956-L972 > Therefore, I feel that the current protocol cannot fully prove whether the producer client can overwrite itself. It may be necessary to add some fields to prove: I am me This is an interesting question. The current design assumes that a producer is "a successor" to a former instance of a producer when it has the same connection. Given the way that producers and the `ServerCnx` are integrated, I think we'd need to refactor the code to remove the connection from the `isSuccessorTo` logic. Perhaps we could achieve producer identity with some kind of UUID passed to the client during producer creation. > The broker will always report an error: `Producer with name is already connect to topic`. This raises another question for me. Should the producer use another name when it attempts to reconnect after certain failures, like a failed keep alive timeout? If the producer tried to connect to a broker and get a new producer name from the broker, it'd circumvent the issue here. It wouldn't work for overridden producer names on the client side. It would also lead to certain edge cases around potential duplicates in the produced messages (this would likely already happen when a keep alive fails). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
