Hi Aljoscha:
Ye, I agree with you that an operator should not see output edges and serialisers. The call getChainIndex() is used only in OperatorConfig.toString(), it can be removed. However, isChainStart() and isChainEnd() is used in AbstractStreamOperator.setup(...). But I think what Stephan meant is only that changing OperatorConfig to be serialisable. If StreamConfig is also serialisable, it need to be serialized into the Configuration, which is underlying before and flows across modules. Do you agree what I understand? Best Regards! Xu Pingyong At 2017-07-05 00:01:34, "Aljoscha Krettek" <aljos...@apache.org> wrote: >Hi, > >Yes, but I think what Stephan was hinting at was to change both of them to be >serialisable when already working on this. > >I think input serialiser is fine to have in OperatorConfig, you’re right! I >don’t see getChainIndex() used anywhere in the code, though. And the output >edges and serialisers also look like they should not be visible to the >operator. > >What do you think? > >Best, >Aljoscha > >> On 4. Jul 2017, at 17:52, xu <xupingyong...@163.com> wrote: >> >> Hi Aljoscha: >> Thanks a lot for your advice. >> >> >> I think I have not need to separate steps, because what I do is only that >> introducing OperatorConfig and moving the fields. StreamConfig still relys >> on an underlying Configuration which flows from client to the jobmanager and >> then to the task. >> >> >> The following configs are used in an operator now: >> 2) input serializer is used in AsyncWaitOperator.class >> 5) chain.index is used in AbstractStreamOperator.setup(...) >> >> >> However, What I put in the OperatorConfig is all configs belong to the >> operator, contains not only the operator uses now, but also the streamTask >> uses to build an operator. By OperatorConfig, an operator can not see >> configs belong to others. >> >> >> Best Regards! >> JiPing >
