TakaHiR07 commented on issue #25041:
URL: https://github.com/apache/pulsar/issues/25041#issuecomment-3640680357

   @mattisonchao 
   Thinks for your clear explanation, that is very helpful for me. Now I 
understand why the previous code is designed for obey the rule "a partition 
topic can not be created if no partition metadata". 
   
   For some other logic, such as admin.deletePartitionedTopic is rely on topic 
metadata. So previous code with this case would have problem (although this 
case I think is hardly happen in actual environment):
   1. user execute admin.updateTopicPartition
   2. "create missing partitions" success but "update topic metadata" fail
   3. user do not execute admin.updateTopicPartition again, and then execute 
admin.deletePartitionTopic
   4. would remain some partitions not delete. 
   
   
   I think set the consumer's default start position to "earliest" maybe is not 
a good way, that would bring a huge compatibility problem, since pulsar and 
other message queue such as kafka, always set default start position to 
"latest". And so many pulsar-client's compatibility would be break. low version 
client may lost message when topic partition updated.
   
   If just change the start position in client#autoUpdatePartitions module, 
that's not complete since maybe pulsar-server update partition, client may 
restart and use default start position "latest" to connect.
   
   
   As for me, I prefer to revert the update step-1,2,3 if without other 
appropriate method. Because previous code's problem is not dangerous. 
   
   I agree that we need to obey the rule "a partition topic can not be created 
if no partition metadata" in some other place such as BrokerService#getTopic(), 
PersistentTopicsBase#internalCreateNonPartitionedTopicAsync(). But in 
admin.updateTopicPartition,  the rule seems is not important. The middle status 
of update topic partition not completely success is not allow in actual 
environment. We normally only allow topic partition update, or not update.
   


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