-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure the deletion consistency of topic and schema #14608
Ensure the deletion consistency of topic and schema #14608
Conversation
pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdTopics.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM except one question.
futures.add(deleteSchema().thenApply(schemaVersion -> null)); | ||
} | ||
|
||
futures.add(deleteSchema().thenApply(schemaVersion -> null)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens to topics with multiple versions fo schema? Will all versions be cleaned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, will delete all the versions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, it's a little confusing for using persistent schema storage for a non-persistent topic, after the broker restart and the producer/consumer will not connect to a non-persistent topic, the non-persistent topic is equivalent to being deleted, In some cases that users using a random name for non-persistent topic, after the application restarts, the topic name will be changes, looks like here will introduce a schema resource leak.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed there is a behavior change that might impact users' applications if the schema auto uploading is disabled.
Before this change, users can delete the topic without deleting schema, so that the application can connect to the newly created topic with the same topic name and existing schema, but after this change, not able to connect to the topic again.
Hmmm, before, users usually use the delete topic to truncate data of the topic. After #10326 introduced truncate topic, I think for now users should to use the truncate method to cleanup data of the topic. So there is no reason why the user still wants to use this topic, but also delete it.
We'd better clarify in the document.
pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/v2/PersistentTopics.java
Outdated
Show resolved
Hide resolved
pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/v2/PersistentTopics.java
Outdated
Show resolved
Hide resolved
futures.add(deleteSchema().thenApply(schemaVersion -> null)); | ||
} | ||
|
||
futures.add(deleteSchema().thenApply(schemaVersion -> null)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, will delete all the versions
futures.add(deleteSchema().thenApply(schemaVersion -> null)); | ||
} | ||
|
||
futures.add(deleteSchema().thenApply(schemaVersion -> null)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, it's a little confusing for using persistent schema storage for a non-persistent topic, after the broker restart and the producer/consumer will not connect to a non-persistent topic, the non-persistent topic is equivalent to being deleted, In some cases that users using a random name for non-persistent topic, after the application restarts, the topic name will be changes, looks like here will introduce a schema resource leak.
I have added explanation in the CLI / API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also help add a test to make sure the schema been removed after the topic has been deleted.
@Parameter(names = { "-d", | ||
"--deleteSchema" }, description = "Delete schema while deleting topic") | ||
@Parameter(names = {"-d", "--deleteSchema"}, description = "Delete schema while deleting topic, " | ||
+ "but the parameter is invalid and the schema is always deleted", hidden = true) | ||
private boolean deleteSchema = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should also update the default value to true?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can't change the default value to true
because that would change its usage.
Before modification: it means false if you don't specify -d
, and it means true if you specify -d
;
After modification: it means true if you don’t specify -d
, but it means false only you specify -d false
.
The two are not fully compatible.
It is similar to #12128
@Parameter(names = { "-d", | ||
"--deleteSchema" }, description = "Delete schema while deleting topic") | ||
@Parameter(names = {"-d", "--deleteSchema"}, description = "Delete schema while deleting topic, " | ||
+ "but the parameter is invalid and the schema is always deleted", hidden = true) | ||
private boolean deleteSchema = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should also update the default value to true?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same with above
if (deleteSchema) { | ||
return pulsar().getBrokerService() | ||
.deleteSchemaStorage(topicName.getPartition(0).toString()) | ||
.thenCompose(unused -> | ||
internalRemovePartitionsAuthenticationPoliciesAsync(numPartitions)) | ||
.thenCompose(unused2 -> | ||
internalRemovePartitionsTopicAsync(numPartitions, force)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If remove these lines, how does the method remove the schema?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
internalRemovePartitionsTopicAsync(numPartitions, force) will delete schema by default.
return t.deleteSchema().thenCompose(schemaVersion -> { | ||
log.info("Successfully delete topic {}'s schema of version {}", t.getName(), schemaVersion); | ||
return t.delete(); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If remove these lines how do we delete the schema?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
t.delete() will delete schema by default.
details: delete() -> delete(boolean,boolean,boolean) -> deleteSchema()
The test testDeleteTopicAndSchemaForV1 in |
* Ensure the deletion consistency of topic and schema (cherry picked from commit c06b17d)
* Ensure the deletion consistency of topic and schema (cherry picked from commit c06b17d)
Master Issue: #12795
Dev email: discuss and reply
Motivation
Deleting topic also deletes its schema.
Documentation
no-need-doc