[
https://issues.apache.org/jira/browse/HDFS-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659047#comment-13659047
]
Todd Lipcon commented on HDFS-4824:
-----------------------------------
Patch looks good. One more thought which might be unnecessarily conservative:
should the cleaner hold a WeakReference to the cache? That way even if users
leak objects it's less likely to get held on forever.
> 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
> Attachments: HDFS-4824.001.patch
>
>
> {{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
