heesung-sn commented on code in PR #17524:
URL: https://github.com/apache/pulsar/pull/17524#discussion_r1449359204
##########
pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentTopic.java:
##########
@@ -268,6 +269,46 @@ protected TopicStatsHelper initialValue() {
@Getter
private final ExecutorService orderedExecutor;
+ private volatile CloseFutures closeFutures;
+
+ /***
+ * We use 3 futures to prevent a new closing if there is an in-progress
deletion or closing. We make Pulsar return
+ * the in-progress one when it is called the second time.
+ *
+ * The topic closing will be called the below scenarios:
+ * 1. Calling "pulsar-admin topics unload". Relate to {@link
CloseFutures#waitDisconnectClients}.
+ * 2. Namespace bundle transfer or unloading.
+ * a. The unloading topic triggered by unloading namespace bundles will
not wait for clients disconnect. Relate
+ * to {@link CloseFutures#notWaitDisconnectClients}.
+ * b. The unloading topic triggered by unloading namespace bundles was
seperated to two steps when using
+ * {@link ExtensibleLoadManagerImpl}.
+ * b-1. step-1: fence the topic on the original Broker, and do not
trigger reconnections of clients. Relate
+ * to {@link CloseFutures#notDisconnectClients}. This step is a half
closing.
+ * b-2. step-2: send the owner broker information to clients and
disconnect clients. Relate
+ * to {@link CloseFutures#notWaitDisconnectClients}.
+ *
+ * The three futures will be setting as the below rule:
+ * Event: Topic close.
+ * - If the first one closing is called by "close and not disconnect
clients":
+ * - {@link CloseFutures#notDisconnectClients} will be initialized as
"close and not disconnect clients".
+ * - {@link CloseFutures#waitDisconnectClients} ang {@link
CloseFutures#notWaitDisconnectClients} will be empty,
+ * the second closing will do a new close after {@link
CloseFutures#notDisconnectClients} is completed.
+ * - If the first one closing is called by "close and not wait for clients
disconnect":
+ * - {@link CloseFutures#waitDisconnectClients} will be initialized as
"waiting for clients disconnect".
+ * - {@link CloseFutures#notWaitDisconnectClients} ang {@link
CloseFutures#notDisconnectClients} will be
+ * initialized as "not waiting for clients disconnect" .
+ * - If the first one closing is called by "close and wait for clients
disconnect", the three futures will be
+ * initialized as "waiting for clients disconnect".
+ * Event: Topic delete.
+ * the three futures will be initialized as "waiting for clients
disconnect".
+ */
+ @AllArgsConstructor
+ private class CloseFutures {
+ private final CompletableFuture<Void> waitDisconnectClients;
+ private final CompletableFuture<Void> notWaitDisconnectClients;
Review Comment:
Why do we need two separate futures here? can't we just combine them,
`closingOrDeleting`?
I think we still need to dedup the closing future from both
cases(waitDisconnectClients and notWaitDisconnectClients).
--
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: commits-unsubscr...@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
