[jira] [Resolved] (REEF-754) Skip deserialization for context and service configuration submitted from .Net to Java

["Markus Weimer (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/REEF-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Markus Weimer resolved REEF-754.
--------------------------------
       Resolution: Fixed
    Fix Version/s: 0.13

Resolved via [#497|https://github.com/apache/incubator-reef/pull/497]

> Skip deserialization for context and service configuration submitted from .Net to Java 
> ---------------------------------------------------------------------------------------
>
>                 Key: REEF-754
>                 URL: https://issues.apache.org/jira/browse/REEF-754
>             Project: REEF
>          Issue Type: Improvement
>            Reporter: Julia
>            Assignee: Julia
>             Fix For: 0.13
>
>
> Currently, .Net code creates Context and Service configuration and submits them to Java over the bridge.  At Java side, it uses the ClassHierarchy created at .Net side to deserialize those configurations. There are a few issues here:
> 1. Some language information could get lost during the class hierarchy deserialization (caused by Java Proto Buffer). That makes Context and Service Configuration validation fail during the configuration deserialization. 
> 2. What are the classes that should be put in the class hierarchy? We do provide a plug in for client to provide the classes that should be build in the class hierarchy. However, if clients don't specify it, we currently default to all the assemblies in the Global folder. There are some third party dlls we don't need to put them in the class hierarchy, and parsing them may cause issues in Tang as .Net may not be able to Load those assemblies and Get Types from them. 
> 3. At Java side, we deserailize those configuration from string to Configuration objects, merge the service configuration with those in CnfigurationProviders and then serialize them back to string again before set them to evaluator configuration. This is not necessary as the configurations in CnfigurationProviders  are for Java evaluator only. All the configurations in ConfigurationProvider for evaluator should have been added at .Net side before service configuration is submitted. 
> 4. deserialize back force causes performance issues.
> We would like to remove the deserialization for context and service configuration at Java side for requests coming from .Net; skip the merge with CnfigurationProviders  for .Net and set those configurations directly when building evaluator configuration. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)