slfan1989 commented on code in PR #8688:
URL: https://github.com/apache/hadoop/pull/8688#discussion_r4093273562
##########
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/token/delegation/ZKDelegationTokenSecretManager.java:
##########
@@ -386,6 +433,24 @@ private void loadFromZKCache(final boolean isTokenCache) {
LOG.info("Loaded {} cache.", cacheName);
}
+ private void awaitCacheInitialized(CountDownLatch initialized,
+ String cacheName) throws IOException {
+ try {
+ if (cacheInitTimeoutMs > 0) {
+ if (!initialized.await(cacheInitTimeoutMs, TimeUnit.MILLISECONDS)) {
+ throw new IOException("Timed out after " + cacheInitTimeoutMs
+ + " ms waiting for " + cacheName + " cache initialization");
+ }
+ } else {
Review Comment:
Could we retain a configurable initialization timeout for production?
If ZooKeeper becomes unavailable after the counters and root paths have been
created but before the cache's persistent watch is registered, `initialized()`
may never be delivered.
ZooKeeper `connection/session` timeouts do not bound this latch wait, so
`startThreads()` can remain blocked indefinitely without reaching the new
failure cleanup.
With the timeout exposed only through a test-only setter, operators cannot
bound this wait.
A configurable timeout would accommodate large caches while allowing
deployments to fail startup and release resources when initialization cannot
complete.
Could we also add a regression test for initialization failure that verifies
startup exits and closes the partially started resources?
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
