hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-13010) Refactor raw erasure coders
Date Wed, 20 Apr 2016 21:48:25 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250781#comment-15250781

Colin Patrick McCabe commented on HADOOP-13010:

bq. Thanks for the discussions Colin / Kai. The "dummy" coders are for tests only. Either
name sounds fine to me. No-op is a more accurate technical description, while dummy better
states the purpose (and therefore prevent users from actually using it). Maybe we can leave
that one open and move this refactor forward.

Yeah, I don't have a strong opinion on "Dummy" versus "NoOp."  Either name could work.  It
also seems reasonable to let users configure this to diagnose issues in the field.  So it
makes sense to keep it in src/ rather than test/.

bq. The suggested way and sample codes look great. It consolidates configurations and coder
options together and has an advantage that the coder options will also be configurable. I
will use it.

Great!  Looking forward to the next revision.

Thanks again, [~drankye] and [~zhz].

> Refactor raw erasure coders
> ---------------------------
>                 Key: HADOOP-13010
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13010
>             Project: Hadoop Common
>          Issue Type: Sub-task
>            Reporter: Kai Zheng
>            Assignee: Kai Zheng
>             Fix For: 3.0.0
>         Attachments: HADOOP-13010-v1.patch, HADOOP-13010-v2.patch, HADOOP-13010-v3.patch
> This will refactor raw erasure coders according to some comments received so far.
> * As discussed in HADOOP-11540 and suggested by [~cmccabe], better not to rely class
inheritance to reuse the codes, instead they can be moved to some utility.
> * Suggested by [~jingzhao] somewhere quite some time ago, better to have a state holder
to keep some checking results for later reuse during an encode/decode call.
> This would not get rid of some inheritance levels as doing so isn't clear yet for the
moment and also incurs big impact. I do wish the end result by this refactoring will make
all the levels more clear and easier to follow.

This message was sent by Atlassian JIRA

View raw message