[
https://issues.apache.org/jira/browse/MAPREDUCE-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189208#comment-14189208
]
Jonathan Eagles commented on MAPREDUCE-6141:
--------------------------------------------
[~jlowe]. Looks good overall. Couple of minor thoughts.
- Should we consider making *mapreduce.jobhistory.recovery.store.class* default
to levelb as part of a follow on jira
- TestHistoryServerLeveldbStateStoreService - please document the test blocks
testTokenStore with comments to help guide the reader of the test code (verify
tokens stored can be read after reload, deleted tokens are really deleted)
- HistoryServerLeveldbStateStoreService - if version in db in null upon
initialization, I think we want to return this as the current version and not
1.0. I think the thought is that we are looking at an uninitialized db. Right
now these values are the same, so I'm just trying to clarify the intention.
- Is the mapreduce-default.xml sufficient documentation to use this feature?
For me it is, but what is your take on it. For example what conditions would
one want to use one over the other?
> History server leveldb recovery store
> -------------------------------------
>
> Key: MAPREDUCE-6141
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6141
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: jobhistoryserver
> Reporter: Jason Lowe
> Assignee: Jason Lowe
> Attachments: MAPREDUCE-6141.patch
>
>
> It would be nice to have a leveldb option to the job history server recovery
> store. Leveldb would provide some benefits over the existing filesystem
> store such as better support for atomic operations, fewer I/O ops per state
> update, and far fewer total files on the filesystem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
