ashutosh-bapat commented on a change in pull request #668: HIVE-21841 : Add
configuration to specify the hostname of HMS leader …to run housekeeping tasks
in.
URL: https://github.com/apache/hive/pull/668#discussion_r294147604
##########
File path:
standalone-metastore/metastore-server/src/main/java/org/apache/hadoop/hive/metastore/HiveMetaStore.java
##########
@@ -9723,7 +9732,6 @@ public static void main(String[] args) throws Throwable {
Lock startLock = new ReentrantLock();
Condition startCondition = startLock.newCondition();
AtomicBoolean startedServing = new AtomicBoolean();
- startMetaStoreThreads(conf, startLock, startCondition, startedServing);
Review comment:
No they aren't. In fact startMetaStore() doesn't know about these threads
(without this change that is). The only condition is that these threads should
be started before we call tServe.serve() as explained by the comment in
startMetaStore().
To expand that point further. The threads are configurable, which means that
a remote metastore may not even run those threads. So, startMetaStore()
shouldn't depend upon those threads.
We can not start these threads unless we know that the current HMS is a
leader HMS. That happens after socket is bound. That's why I had to push
startMetaStoreThreads() inside startMetaStore(). The way it's placed now, we
won't spend time in starting these threads when the bind fails or creating
TServer thread pool fails for any reason. So, we are actually saving on some
resources in case of failures.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
