[
https://issues.apache.org/jira/browse/HADOOP-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brice Arnould updated HADOOP-3609:
----------------------------------
Attachment: ExpiringHashSet.patch
This is a proposal of an ExpiringHashSet implemented with a LinkedHashMap.
Another option would be to use a ConcurrentHashSet to remember what we removed
and a DelayQueue to describe the queue. I'm unsure about which is better.
I think that this proposal relates to [HADOOP-3608], because it helps to
simplify the use of containers and to reduce the time during which monitors are
locked. It also adds some tests as discussed in that bug.
However, I must admit that it is a pretty big patch for no new functionality.
> Refactor JobTracker.Expire* arround an utility class
> ----------------------------------------------------
>
> Key: HADOOP-3609
> URL: https://issues.apache.org/jira/browse/HADOOP-3609
> Project: Hadoop Core
> Issue Type: Improvement
> Components: mapred, util
> Reporter: Brice Arnould
> Priority: Minor
> Attachments: ExpiringHashSet.patch
>
>
> I would like to propose a new class, called ExpiringHashSet, which could
> factorize the code from JobTracker.ExpireLaunchingTasks and
> JobTracker.ExpireTrackers.
> It behaves like an ordinary HashSet, but adds two methods and one argument to
> the constructor.
> That argument, {{lifeTime}}, tells after how much milliseconds an element
> added to the container expire and is removed.
> The first method, {{update(element)}}, takes an element as it argument and
> delay it's expiration by {{lifeTime}} milliseconds.
> The last method, {{makeExpire}} is called by the ExpiringHashSet just before
> it remove an old item. If that method return false, the item won't be removed.
> Nothing expire while we're synchronized on the ExpiringHashSet.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
