nodece commented on a change in pull request #13596:
URL: https://github.com/apache/pulsar/pull/13596#discussion_r786804724



##########
File path: 
pulsar-metadata/src/main/java/org/apache/pulsar/metadata/impl/ZKMetadataStore.java
##########
@@ -186,6 +188,12 @@ protected void batchOperation(List<MetadataOp> ops) {
                     }
                 }
             }, null);
+
+            executor.schedule(() -> {
+                if (!callback.get()) {
+                    ops.forEach(n -> n.getFuture().completeExceptionally(new 
TimeoutException()));
+                }
+            }, getMetadataStoreConfig().getOperationTimeoutSeconds(), 
TimeUnit.SECONDS);

Review comment:
       > If the broker acquired a lock from Zookeeper but the operation timeout 
happened first, the callback happened later, how do we deal with this case?
   
   We cannot determine the order, maybe we should avoid using `future.join()` 
in our project, but I still care when the zk doesn't call the callback, we 
should how to release a future.
   
   > I think the main point is to find the root cause of why the the zk doesn't 
call the callback, is the performance bottleneck or deadlock?
   
   I have found the root cause of zk doesn't call the callback, and I submitted 
#13809 to fix this. 
   




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