[
https://issues.apache.org/jira/browse/HADOOP-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15247723#comment-15247723
]
Kai Zheng commented on HADOOP-13010:
------------------------------------
bq. Sure. In that case, we should document that these objects are not
guaranteed to be thread-safe, so that there is no confusion.
Ah, ok, it should be documented.
bq. ErasureCoderConf#setCoderOption / ErasureCoderConf#getCoderOption: I don't
see why we need to have these. If these options are generic to all erasure
encoders, then they can just go as "regular java fields" like
ErasureCoderConf#numDataUnits, etc. On the other hand, if these options only
apply to one type of Coder, then they should be stored in the particular type
of coder they apply to.
I thought the suggestion is good for the new approach, as we don't have
interface now, so it's good to get rid of the generic options container (map).
Whenever we need to add a new option, we can just add it to the
encoder/decoder. Note the current options are generic and common to all coders,
so I can add them to the base encoder/decoder classes.
bq. The usual way to do this is to have your Encoder / Decoder class take a
Configuration object as an argument, and pull out whatever values it needs...
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.
> 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
(v6.3.4#6332)
