[
https://issues.apache.org/jira/browse/HDFS-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13657611#comment-13657611
]
Colin Patrick McCabe commented on HDFS-4824:
--------------------------------------------
yeah, we definitely should be checking that return code. I'm still confused
about whether we should be able to cancel via the runnable or not. The types
seem right, but there might be some issues surrounding Runnables that wrap
other Runnables... I will test.
It's better to cancel via the future anyway, I think.
> FileInputStreamCache.close leaves dangling reference to
> FileInputStreamCache.cacheCleaner
> -----------------------------------------------------------------------------------------
>
> Key: HDFS-4824
> URL: https://issues.apache.org/jira/browse/HDFS-4824
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs-client
> Affects Versions: 2.0.4-alpha
> Reporter: Henry Robinson
> Assignee: Colin Patrick McCabe
>
> {{FileInputStreamCache}} leaves around a reference to its {{cacheCleaner}}
> after {{close()}}.
> The {{cacheCleaner}} is created like this:
> {code}
> if (cacheCleaner == null) {
> cacheCleaner = new CacheCleaner();
> executor.scheduleAtFixedRate(cacheCleaner, expiryTimeMs,
> expiryTimeMs,
> TimeUnit.MILLISECONDS);
> }
> {code}
> and supposedly removed like this:
> {code}
> if (cacheCleaner != null) {
> executor.remove(cacheCleaner);
> }
> {code}
> However, {{ScheduledThreadPoolExecutor.remove}} returns a success boolean
> which should be checked. And I _think_ from a quick read of that class that
> the return value of {{scheduleAtFixedRate}} should be used as the argument to
> {{remove}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
