Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> Re-swizzle 2.3


Copy link to this message
-
Re: Re-swizzle 2.3
Do you guys think that committing
    https://issues.apache.org/jira/browse/HDFS-4858
to branch-2.3 is still Ok? It is a small change that bring fixes broken
timeout behavior of DN to NN RPC.

We have been testing this fix on top of 2.0.6 for a long time now and it seems
to be a real help.

Appreciate the feedback on 2.3 scope. If it is too late then I will commit it
to trunk, branch-2.4 and branch-2 only.

Regards,
  Cos

On Thu, Feb 06, 2014 at 05:44PM, Alejandro Abdelnur wrote:
> yep, the idea is to pull all of them out from branch2.3. things go back to normal then.
>
> thanks
>
> Alejandro
> (phone typing)
>
> > On Feb 6, 2014, at 17:39, Zhijie Shen <[EMAIL PROTECTED]> wrote:
> >
> > Recently I brought 4 JIRAs to branch-2.3, which are MAPREDUCE-5743, YARN-1628,
> > YARN-1661 and YARN-1689. Recall that we mark test failure fixes as blockers
> > for pior releases as closing to release, thus I brought to branch-2.3
> > MAPREDUCE-5743
> > and YARN-1628 that are the fixes for the test failure on 2.3.0, but didn't
> > marked them as blockers. Please let me know if I should do that.
> >
> > YARN-1661 is a fix for exit log of DS AppMaster, otherwise the exit log of
> > it will always be failure, which sounds a critical issue to me. Feel free
> > to pull it out if any objects.
> >
> > YARN-1689 is brought to branch-2.3 as YARN-1493 is still in this branch. It
> > fixes one bug caused by YARN-1493. Those should be included or excluded
> > together upon the decision.
> >
> > Thanks,
> > Zhijie
> >
> >
> >> On Thu, Feb 6, 2014 at 5:15 PM, Sandy Ryza <[EMAIL PROTECTED]> wrote:
> >>
> >> +1 to reverting those JIRAs from branch-2.3.  As YARN-1689 is fixing a
> >> problem caused by YARN-1493 I think we can revert it in branch-2.3 as well.
> >>
> >> I think we should leave them in branch-2 for now.  We can revert if 2.4 is
> >> imminent and they're holding it up, but hopefully the issues they caused
> >> will be fixed by then.
> >>
> >> -Sandy
> >>
> >>
> >> On Thu, Feb 6, 2014 at 5:07 PM, Alejandro Abdelnur <[EMAIL PROTECTED]
> >>> wrote:
> >>
> >>> Thanks Robert,
> >>>
> >>> All,
> >>>
> >>> So it seems that YARN-1493 and YARN-1490 are introducing serious
> >>> regressions.
> >>>
> >>> I would propose to revert them and the follow up JIRAs from the 2.3
> >> branch
> >>> and keep working on them on trunk/branch-2 until the are stable (I would
> >>> even prefer reverting them from branch-2 not to block a 2.4 if they are
> >> not
> >>> ready in time).
> >>>
> >>> As I've mentioned before, the list of JIRAs to revert were:
> >>>
> >>> YARN-1493
> >>> YARN-1490
> >>> YARN-1166
> >>> YARN-1041
> >>> YARN-1566
> >>>
> >>> Plus 2 additional JIRAs committed since my email on this issue 2 days
> >> ago:
> >>>
> >>> *YARN-1661
> >>> *YARN-1689 (not sure if this JIRA is related in functionality to the
> >>> previous ones but it is creating conflicts).
> >>>
> >>> I think we should hold on continuing work on top of something that is
> >>> broken until the broken stuff is fixed.
> >>>
> >>> Quoting Arun, "Committers - Henceforth, please use extreme caution while
> >>> committing to branch-2.3. Please commit *only* blockers to 2.3."
> >>>
> >>> YARN-1661 & YARN-1689 are not blockers.
> >>>
> >>> Unless there are objections, I'll revert all these JIRAs from branch-2.3
> >>> tomorrow around noon and I'll update fixedVersion in the JIRAs.
> >>>
> >>> I'm inclined to revert them from branch-2 as well.
> >>>
> >>> Thoughts?
> >>>
> >>> Thanks.
> >>>
> >>>
> >>> On Thu, Feb 6, 2014 at 3:54 PM, Robert Kanter <[EMAIL PROTECTED]>
> >>> wrote:
> >>>
> >>>> I think we should revert YARN-1490 from Hadoop 2.3 branch.  I think it
> >>> was
> >>>> causing some strange behavior in the Oozie unit tests:
> >>>>
> >>>> Basically, we use a single MiniMRCluster and MiniDFSCluster across all
> >>> unit
> >>>> tests in a module.  With YARN-1490 we saw that, regardless of test
> >> order,
> >>>> the last few tests would timeout waiting for an MR job to finish; on

 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB