codelipenghui commented on PR #21144: URL: https://github.com/apache/pulsar/pull/21144#issuecomment-1713041173
@poorbarcode > No, the PR https://github.com/apache/pulsar/pull/12846 just used isSuccessorTo instead of hashcode & equals. Oh, thanks for the explanation. It hasn't changed the behavior. > In our design, we assume that the IO events are sequential. But one producer/consumer can use different connections, making the sequential broken. I think the current solution is better. This is quite convincing. How about the connection being broken? Both the broker and client will handle the `channelInactive` event. However, the order of completion remains unknown to us. If the broker hasn't done the cleanup job from the broken connection, but the client tries to re-create the producer with a new connection. Will the client still get a `producer already connected` error? Maybe we should fix both of them? The client always uses the same connection only when the connection is not available. The broker should make sure the same producer with a newer epoch can fence the existing producer with an older epoch. -- 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]
