[jira] [Resolved] (MAPREDUCE-3135) Unit test org.apache.hadoop.mapred.TestJobHistoryServer fails intermittently
[ https://issues.apache.org/jira/browse/MAPREDUCE-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ravi Prakash resolved MAPREDUCE-3135. - Resolution: Duplicate Release Note: Presumably TestJobHistoryServer is working fine after MAPREDUCE-4798 > Unit test org.apache.hadoop.mapred.TestJobHistoryServer fails intermittently > > > Key: MAPREDUCE-3135 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-3135 > Project: Hadoop Map/Reduce > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Ravi Prakash > > Every once in a while org.apache.hadoop.mapred.TestJobHistoryServer fails due > to a timeout. -- 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
[jira] [Created] (MAPREDUCE-5306) HistoryFileManager.mkdir() doesn't handle case where dest path exists -and is a file
Steve Loughran created MAPREDUCE-5306:
-
Summary: HistoryFileManager.mkdir() doesn't handle case where dest
path exists -and is a file
Key: MAPREDUCE-5306
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5306
Project: Hadoop Map/Reduce
Issue Type: Bug
Reporter: Steve Loughran
Priority: Minor
The {{HistoryFileManager.mkdir()}} code handles the path existing simply by
logging that the dir exists, and returning for everything else to work.
There's a big assumption there: that the path resolves to a directory. A check
needs to be made that this assumption is valid -throwing some IOE subclass if
it's just a file
--
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
[jira] [Created] (MAPREDUCE-5305) AggregatedLogDeletionService may delete recent stuff if its clock is out of sync
Steve Loughran created MAPREDUCE-5305:
-
Summary: AggregatedLogDeletionService may delete recent stuff if
its clock is out of sync
Key: MAPREDUCE-5305
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5305
Project: Hadoop Map/Reduce
Issue Type: Bug
Components: jobhistoryserver
Affects Versions: 3.0.0, 2.1.0-beta
Reporter: Steve Loughran
Priority: Minor
The {{AggregatedLogDeletionService}} compares file time with current time
before deciding whether to delete things. If the clock on the system is
sufficiently wrong, it may overreact.
If this is felt to be an issue, the fix would be for it to create a file on the
DFS, stat it, and work out out the offset.
--
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
[jira] [Created] (MAPREDUCE-5304) mapreduce.Job killTask/failTask/getTaskCompletionEvents methods have incompatible signature changes
Alejandro Abdelnur created MAPREDUCE-5304:
-
Summary: mapreduce.Job killTask/failTask/getTaskCompletionEvents
methods have incompatible signature changes
Key: MAPREDUCE-5304
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5304
Project: Hadoop Map/Reduce
Issue Type: Bug
Affects Versions: 2.0.4-alpha
Reporter: Alejandro Abdelnur
Assignee: Karthik Kambatla
Priority: Blocker
Fix For: 2.1.0-beta
Pointed out by [~zjshen] in MAPREDUCE-4942.
In {{o.a.h.mapreduce.Job}} class, the following changed from Hadoop 1 to Hadoop
2.
boolean failTask(TaskAttemptID): Change in return type from void to boolean.
boolean killTask(TaskAttemptID): Change in return type from void to boolean.
TaskCompletionEvent[] getTaskCompletionEvents(int): Change in return type from
org.apache.hadoop.mapred.TaskCompletionEvent[] to
org.apache.hadoop.mapreduce.TaskCompletionEvent[].
Using same rational as in other JIRAs, we should fix this to ensure Hadoop 1 to
Hadoop 2 source compatibility (taking 0.23.x releases as a casualty as there is
not right way for everybody because we screwed up :( ). Flagging it as
incompatible change because of 0.23.
--
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
Re: Heads up: branch-2.1-beta
On Tue, Jun 4, 2013 at 8:32 AM, Arun C Murthy wrote: > Folks, > > The vast majority of of the planned features and API work is complete, > thanks to everyone who contributed! > > I've created a branch-2.1-beta branch from which I anticipate I can make the > first of our beta releases very shortly. > > For now the remaining work is to wrap up loose ends i.e. last minute api > work (e.g. YARN-759 showed up last night for consideration), > bug-fixes etc.; then run this through a battery of unit/system/integration > tests and do a final review before we ship. There is more > work remaining on documentation (e.g. HADOOP-9517) and I plan to personally > focus on it this week - obviously help reviewing docs > is very welcome. On the Bigtop side of things, once we have stable Bigtop 0.6.0 platform based on Hadoop 2.0.x codeline we plan to start running the same battery of integration tests on the branch-2.1-beta. We plan to simply file JIRAs if anything gets detected and I will also publish the URL of the Jenkins job once it gets created. Let me know if there's anything else Bigtop can help with to make 2.1-beta a success. Thanks, Roman.
