codelipenghui commented on pull request #13949:
URL: https://github.com/apache/pulsar/pull/13949#issuecomment-1021854190


   We should apply this change carefully.
   
   If the client is like the followings:
   
   1. The client sends the command to create the producer
   2. The broker received the command and start to process the request, but 
can't complete it after the client-side operation timeout
   3. The client tries to send a new create producer command with the same 
producer ID but a different request ID (Of course this usually doesn't happen)
   4. Now the broker received the new create producer command and will use the 
existing `future` 
https://github.com/apache/pulsar/blob/master/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/ServerCnx.java#L1173
 to process the new request.
   5. Then the previous request failed, and complete the future with an 
exception
   6. The client will not able to receive the response for the second request.
   
   In my opinion, we should handle such case in the following principles:
   
   1. The server side should return a response to the client, one producer 
future might map to multiple request IDs, we should avoid broker miss response 
to the client, of course, if the connection is not available, there is no way 
to make the above guarantee.
   2. The client-side should make sure to only process one response for a 
request ID, if the request ID has already been finished by another response, 
the client to ignore the subsequent responses.
   
   I think it's the more easy and clear way to handle both the client-side and 
server-side. And currently, the client-side also follow this way 
https://github.com/apache/pulsar/blob/master/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ClientCnx.java#L534,
 
https://github.com/apache/pulsar/blob/master/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ClientCnx.java#L719


-- 
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]


Reply via email to