This message was deleted.

Good question @Girish Sharma.

I am assuming there are watches on this path so that the relevant broker (bundle owner) understands this and creates any increased partitions?

I don't think that bundle owners do anything when the partitions are increased. Pulsar simply waits for a producer or consumer to connect before anything is done. The clients are the ones that are active when the partitions are increased. In Pulsar Java client, the producer's and consumer's

autoUpdatePartitions/autoUpdatePartitionsInterval

settings control this.

I see. Yes, i did find that code path for sure. Then what about topic deletion leading to individual brokers deleting their local topic object reference?

Then what about topic deletion leading to individual brokers deleting their local topic object reference?

@Girish Sharma With a quick glance I didn't find code that would delete partitions when the the number of partitions is reduced. It's possible that handling is missing and each individual topic for the removed partitions should be deleted manually.

That's probably because partition scale down isnt supported.... I was talking about complete partitioned topic deletion

> That's probably because partition scale down isnt supported That's right. > I was talking about complete partitioned topic deletion @Girish Sharma You can drill down into the source of partitioned topic deletion starting here: https://github.com/apache/pulsar/blob/c3f1ee01a376541dde8a5deda7ee99c0beb65dc0/pul[…]in/java/org/apache/pulsar/broker/admin/v2/PersistentTopics.java In more detail here: https://github.com/apache/pulsar/blob/c3f1ee01a376541dde8a5deda7ee99c0beb65dc0/pul[…]a/org/apache/pulsar/broker/admin/impl/PersistentTopicsBase.java btw. There's actually something in the logic that doesn't make sense. It should behave in a way where the partitioned topic should be marked deleted in the top level partitioned topic metadata before removing the individual partition topics (*-partition-n). That doesn't seem to be the case currently. It first removes the individual partition topics and after that marks the topic deleted.

Thanks! So it basically calls the partition delete admin api and relies on redirects to eventually land on the owning broker of the partition... For why it deleted the partitions is because if that deletion fails in between, the topic metadata remains in tact and missing partitions can be recreated... (Basically a revert). Not possible if done the other way round. At least that's what I could think of.

> So it basically calls the partition delete admin api and relies on redirects to eventually land on the owning broker of the partition... Yes > > For why it deleted the partitions is because if that deletion fails in between, the topic metadata remains in tact and missing partitions can be recreated... (Basically a revert). Not possible if done the other way round. At least that's what I could think of. That's not how it is currently implemented. One would assume that it would be implemented that way. My understanding is that the main point of the deletion flag for the top level partitioned topic is to prevent individual topic partitions getting re-created while the deletion is in progress. Here is some of that reverting behavior currently. The deletion flag is set before deleting the actual top level partitioned topic. However, it's not really needed in that case at all. this location: https://github.com/apache/pulsar/blob/c3f1ee01a376541dde8a5deda7ee99c0beb65dc0/pul[…]a/org/apache/pulsar/broker/admin/impl/PersistentTopicsBase.java The logic has also been added to locations where the top level partitioned topic isn't handled at all. There's no in memory "PersistentTopic" instance for the top level partitioned topic and some of the deletion logic is there. It looks like authentication policies are dropped instead of marking the top level topic partition deleted: https://github.com/apache/pulsar/blob/c3f1ee01a376541dde8a5deda7ee99c0beb65dc0/pul[…]a/org/apache/pulsar/broker/admin/impl/PersistentTopicsBase.java I guess this solution existed before the soft deletion for the (top level) partitioned topic was added.