[
https://issues.apache.org/jira/browse/MAPREDUCE-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246244#comment-13246244
]
Bhallamudi Venkata Siva Kamesh commented on MAPREDUCE-4059:
-----------------------------------------------------------
A minor comment: I think, while comparing enum types it is better to use "=="
rather than "equals" method.
{code:title=CachedHistoryStorage.java|borderStyle=solid}
if(jobState != null && !jobState.equals(report.getJobState())) {
continue;
}
{code}
Also please go through the following point and clarify
If all the implementations of the HistoryStorage interacts with the
HistoryFileManager manager, I think, it is better to make HistoryStorage as an
abstract class, and moving the common boilerplate code to HistoryStorage like
init etc.... Currently HistoryFileManager is the only class that is
used to interact with history files stored in the HDFS. But as per my
understading of
[MAPREDUCE-3973|https://issues.apache.org/jira/browse/MAPREDUCE-3973?focusedCommentId=13226450&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13226450],
these job history files can be stored in a differnt store as well?. If this is
the case how to manage files stored in a different store (any different
implementation)?
> The history server should have a separate pluggable storage/query interface
> ---------------------------------------------------------------------------
>
> Key: MAPREDUCE-4059
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-4059
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: mrv2
> Affects Versions: 0.24.0, 0.23.3
> Reporter: Robert Joseph Evans
> Assignee: Robert Joseph Evans
> Attachments: MR-4059.txt, MR-4059.txt, MR-4059.txt, MR-4059.txt
>
>
> The history server currently caches all parsed jobs in RAM. These jobs can
> be very large because of counters. It would be nice to have a pluggable
> interface for the cacheing and querying of the cached data so that we can
> play around with different implementations. Also just for cleanness of the
> code it would be nice to split the very large JobHistoryServer.java into a
> few smaller ones that are more understandable and readable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
