[jira] [Updated] (REEF-750) Tang should not force loading of DLLs not required at application runtime

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

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

Anupam updated REEF-750:
------------------------
    Description: 
In usual .NET execution, if assembly A has code dependency on assembly B but in a certain run none of the code which depends on assembly B is executed, assembly B is not be required/loaded by CLR.

When we use Tang, there are at least two scenarios which break the above assumption.
 * We try to load all assemblies in global folder in driver. In this scenario, an assembly which has dependency on native assemblies will fail to load even though this assembly is not required at runtime. Trivial workaround for user is to remove the offending assembly, but instead the error will prompt the user to add the missing assemblies.
 * We try to walk the class hierarchy for all provided assemblies, which makes us try to traverse a transitive closure of the class dependency relationship. For an application residing in complex code-base, this is not desirable.

We could fix this by:
 * Do not proactively load all assemblies.
 * Do not try to generate complete class hierarchy (which is needed for inter-operability between Java and C# Tang)

In short term:
 * We stop chasing down a path in dependency graph once we cannot find assembly for a type and log the error.
 * Make the above failure available only when someone tries to instantiate a type for which the dependencies are not available.

  was:
In usual .NET execution, if assembly A has code dependency on assembly B but in a certain run none of the code which depends on assembly B is executed, assembly B is not be required/loaded by CLR.

When we use Tang, there are at least two scenarios which break the above assumption.
 * We try to load all assemblies in global folder in driver. In this scenario, an assembly which has dependency on native assemblies will fail to load even though this assembly is not required at runtime. Trivial workaround for user is to remove the offending assembly, but instead the error will prompt the user to add the missing assemblies.
 * We try to walk the class hierarchy for all provided assemblies, which makes us try to traverse a transitive closure of the class dependency relationship. For an application residing in complex code-base, this is not desirable.



> Tang should not force loading of DLLs not required at application runtime
> -------------------------------------------------------------------------
>
>                 Key: REEF-750
>                 URL: https://issues.apache.org/jira/browse/REEF-750
>             Project: REEF
>          Issue Type: Bug
>          Components: Tang.NET
>            Reporter: Anupam
>
> In usual .NET execution, if assembly A has code dependency on assembly B but in a certain run none of the code which depends on assembly B is executed, assembly B is not be required/loaded by CLR.
> When we use Tang, there are at least two scenarios which break the above assumption.
>  * We try to load all assemblies in global folder in driver. In this scenario, an assembly which has dependency on native assemblies will fail to load even though this assembly is not required at runtime. Trivial workaround for user is to remove the offending assembly, but instead the error will prompt the user to add the missing assemblies.
>  * We try to walk the class hierarchy for all provided assemblies, which makes us try to traverse a transitive closure of the class dependency relationship. For an application residing in complex code-base, this is not desirable.
> We could fix this by:
>  * Do not proactively load all assemblies.
>  * Do not try to generate complete class hierarchy (which is needed for inter-operability between Java and C# Tang)
> In short term:
>  * We stop chasing down a path in dependency graph once we cannot find assembly for a type and log the error.
>  * Make the above failure available only when someone tries to instantiate a type for which the dependencies are not available.



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