[
https://issues.apache.org/jira/browse/HIVE-21312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16780724#comment-16780724
]
Zoltan Haindrich commented on HIVE-21312:
-----------------------------------------
{quote}<Void> is intentional and hence returning null. Getting the future value
within the loop would be blocking call and would make it sequential as it has
to wait for the result.
{quote}
I think future.get() will wait for the "null" which was returned from the
Callable; I still think you should remove the concurrect collection.
{quote}Thread id `stats-updater-thread-%d` would be helpful in debugging
{quote}
well; it will not show up in a grep for the query's thread...but sure no big
deal...it's in trace log anyway
{quote}Having fixed threadpool would help restricting the number of threads to
corepool. If few files are used, it would not go beyond the threadpool size.
But if cached thread pool is used, it can create too many number of threads
(not boundeded). Hence the usage of fixed threadpool.
{quote}
damn...I keep forgetting this...the constructor of ThreadPoolExecutor lets this
...but it's missing on the Executors api...
I've just noticed this...please don't catch (and handle Exception); the old
behaviour was to log the exception and **return false** as the operation was
unsuccessfull...
{code:java}
} catch(Exception e)
Utilities.FILE_OP_LOGGER.error("Reading stats : " +
file.getPath(), e)
} finally {
{code}
> FSStatsAggregator::connect is slow
> ----------------------------------
>
> Key: HIVE-21312
> URL: https://issues.apache.org/jira/browse/HIVE-21312
> Project: Hive
> Issue Type: Improvement
> Components: Statistics
> Reporter: Rajesh Balamohan
> Assignee: Rajesh Balamohan
> Priority: Trivial
> Attachments: HIVE-21312.1.patch, HIVE-21312.2.patch,
> HIVE-21312.3.patch, HIVE-21312.4.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
