[
https://issues.apache.org/jira/browse/MAPREDUCE-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527480#comment-13527480
]
Avner BenHanoch commented on MAPREDUCE-4049:
--------------------------------------------
Alejandro,
I am repeating my [previous
comment|https://issues.apache.org/jira/browse/MAPREDUCE-4049?focusedCommentId=13504502&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13504502]
that your behavior is inappropriate and unfriendly.
* Your interest in this JIRA issue was only started to be shown 2 weeks ago,
exactly 2 hours after Arun's last comment in MAPREDUCE-2454, in which Arun kept
persisting his concern for the core of MapReduce with the massive changes that
the huge patch there introduces, and requested breaking it into subtasks.
* At that phase my trivial patch already passed a long way and was ready for
the trunk (beside minor last request just to rename functions in one class).
But then you woke up and started to ask many new things.
I was always concerned that linking our issues will delay one for the other,
instead of letting each progress at its own pace (and this is just 3 months
after Asokan already tried to delay my issue and wanted to first submit his
patch).
*You promised many times that all this will delay me just in few days.* See
the course of your promises to me *(all quotes are taken from you in this
JIRA)*:
* Your original justification for the linking was: _"As all this JIRAs are
small, I think we'll be able *to move fast with all of them*"_.
* You responded: _"If that requires *a couple of extra days*, is is a small
price to pay"_.
* You clarified: _"And don't worry about begin a subtask delaying it, I'll
review it as soon as you post a patch and committed it when ready. The same is
happening with the other subtasks, *so things should be in quite quickly*. Thx"_
*Now, what happened:*
* *I fulfilled ALL your requests* including those that are {color:red}_"to
have a consistent set of names and APIs (ie inner Context) for a set of related
plugins (all the ones affected by MAPREDUCE-2454)"_{color}, then, *you
personally reviewed my patch and you personally +1 it*.
* This Friday you promised again to *merge to trunk -_"fast, by the end of
next week if no surprises arise"_*.
* Then *you personally merged it to your branch*. After that *Arun merged it
to trunk too*.
* Then you broke all your past commitments and responded with: _*"-1 this
patch to go in trunk until the work in the branch is completed."*_
*Sorry. I don’t get it!*
* My patch contains all your requests, including those that are
{color:red}_"to have a consistent set of names and APIs (ie inner Context) for
a set of related plugins (all the ones affected by MAPREDUCE-2454)"_{color},
and you personally +1 it and merged it to your branch. *How can be that it
suits your branch, but not the trunk because of your branch needs???*
* Personally, watching the design (and performance) questions on
MAPREDUCE-2454 I have no idea when this patch will ever be accepted to trunk.
*I don’t think it is appropriate to block my trivial patch to go to the trunk.
{color:red}My patch stands for itself.{color}* There are many people that are
waiting for it and wanting it.
* Per your request, my patch got the tags @Unstable and @limittedPrivate. You
always have the option to iron its code, in the same way that you can do with
any code in SVN.
* Your _"-1 this patch to go in trunk until the work in the branch is
completed"_ *literally says that you took my issue as {color:red}hostage{color}
for MAPREDUCE-2454* despite your promises that these steps will not delay me.
> plugin for generic shuffle service
> ----------------------------------
>
> Key: MAPREDUCE-4049
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-4049
> Project: Hadoop Map/Reduce
> Issue Type: Sub-task
> Components: performance, task, tasktracker
> Affects Versions: 1.0.3, 1.1.0, 2.0.0-alpha, 3.0.0
> Reporter: Avner BenHanoch
> Assignee: Avner BenHanoch
> Labels: merge, plugin, rdma, shuffle
> Fix For: 3.0.0
>
> Attachments: HADOOP-1.x.y.patch, Hadoop Shuffle Plugin Design.rtf,
> mapreduce-4049.patch, mapreduce-4049.patch, mapreduce-4049.patch,
> mapreduce-4049.patch, mapreduce-4049.patch, mapreduce-4049.patch
>
>
> Support generic shuffle service as set of two plugins: ShuffleProvider &
> ShuffleConsumer.
> This will satisfy the following needs:
> # Better shuffle and merge performance. For example: we are working on
> shuffle plugin that performs shuffle over RDMA in fast networks (10gE, 40gE,
> or Infiniband) instead of using the current HTTP shuffle. Based on the fast
> RDMA shuffle, the plugin can also utilize a suitable merge approach during
> the intermediate merges. Hence, getting much better performance.
> # Satisfy MAPREDUCE-3060 - generic shuffle service for avoiding hidden
> dependency of NodeManager with a specific version of mapreduce shuffle
> (currently targeted to 0.24.0).
> References:
> # Hadoop Acceleration through Network Levitated Merging, by Prof. Weikuan Yu
> from Auburn University with others,
> [http://pasl.eng.auburn.edu/pubs/sc11-netlev.pdf]
> # I am attaching 2 documents with suggested Top Level Design for both plugins
> (currently, based on 1.0 branch)
> # I am providing link for downloading UDA - Mellanox's open source plugin
> that implements generic shuffle service using RDMA and levitated merge.
> Note: At this phase, the code is in C++ through JNI and you should consider
> it as beta only. Still, it can serve anyone that wants to implement or
> contribute to levitated merge. (Please be advised that levitated merge is
> mostly suit in very fast networks) -
> [http://www.mellanox.com/content/pages.php?pg=products_dyn&product_family=144&menu_section=69]
--
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
