Add custom ClassLoaders to Geode after startup

[Vahram Aharonyan <va...@vmware.com>]

Hi,

Currently we are facing issues with letting Geode to know about our java plugins that are being loaded on distributed system members during runtime.
Jira story about this is opened by us recently - GEODE-3904.
Just posting here to understand if others have hit this kind of issue or to have additional thoughts that can help us addressing this issue.

Specifically, our issue occurs when we try to perform some action that causes serialization/deserialization of objects that are instance of classes coming from plugin JARs. To successfully complete these operations Geode need to have this plugin jars/classLoaders in its ClassPathLoader.

In Geode versions prior to 1.2.0 it was possible to achieve this goal by invoking internal ClassPathLoader#addOrReplaceAndSetLatest API. This piece of code was removed in 1.2.0 as a part of ClassPathLoader changes to rely on single URLClassLoader. After this change alternate way to update Geode class loaders is to deploy plugin Jar but this does not seem to be possible due to the following:

1. Per documentation, clean way for user to deploy a JAR is only with usage of gfsh. There is no public API that allows user programs to perform JAR deployment runtime once cluster/member startup is already finished.
2. With usage of internal API (org.apache.geode.internal.JarDeployer#deploy(java.lang.String[], byte[][])) it seems that org.apache.geode.internal.ClassPathLoader#classLoaderForDeployedJars is getting overwritten with every deploy attempt. Hence it is not possible to invoke this internal API in user application multiple times to load different jars and classloader to GEODE classPathLoader on the fly.
3. For dynamic plugging of jar it is enough just to add corresponding classLoader to Geode ClassPathLoader, hence required classes will be loaded once needed and it is not necessary to have another copy of that JAR in deployment directory, keep versioning of that and afterwards take care of undeploying it to release consumed resources.

So we think that giving some API to user that will allow to dynamically load/unload specific ClassLoader to ClassPathLoader will address this issue. Could anyone please kindly share his thoughts on this?

Thanks,
Vahram

RE: Add custom ClassLoaders to Geode after startup

[Vahram Aharonyan <va...@vmware.com>]

Hi Jens,

Request is for official java API that will allow to add user defined ClassLoader to Geode ClassPath after startup. It is not mandatory to have whole “gfsh deploy” command mimicked. The main idea is to let Geode know about new plugin classes that are being loaded to the application during runtime. This could be achieved without jar deployment. Adding of custom ClassLoaders to somewhere and populating them on org.apache.geode.internal.ClassPathLoader#getClassLoaders call along with already existing ones could be enough. Because the main idea is to have plugin classes available once any object instantiated from them is going to be used for serialization or deserialization. BTW, could it be I’m missing something and there is already other way to achieve this?

Thanks,
Vahram.

From: Jens Deppe [mailto:jensdeppe@apache.org]
Sent: Thursday, October 26, 2017 12:15 AM
To: user@geode.apache.org
Subject: Re: Add custom ClassLoaders to Geode after startup

Hi Vahram,

I'm not entirely clear what your use case is. Are you asking for an official java API which mimics the "gfsh deploy command"?

--Jens


On Wed, Oct 25, 2017 at 5:54 AM, Vahram Aharonyan <va...@vmware.com>> wrote:
Hi,

Currently we are facing issues with letting Geode to know about our java plugins that are being loaded on distributed system members during runtime.
Jira story about this is opened by us recently - GEODE-3904.
Just posting here to understand if others have hit this kind of issue or to have additional thoughts that can help us addressing this issue.

Specifically, our issue occurs when we try to perform some action that causes serialization/deserialization of objects that are instance of classes coming from plugin JARs. To successfully complete these operations Geode need to have this plugin jars/classLoaders in its ClassPathLoader.

In Geode versions prior to 1.2.0 it was possible to achieve this goal by invoking internal ClassPathLoader#addOrReplaceAndSetLatest API. This piece of code was removed in 1.2.0 as a part of ClassPathLoader changes to rely on single URLClassLoader. After this change alternate way to update Geode class loaders is to deploy plugin Jar but this does not seem to be possible due to the following:

1. Per documentation, clean way for user to deploy a JAR is only with usage of gfsh. There is no public API that allows user programs to perform JAR deployment runtime once cluster/member startup is already finished.
2. With usage of internal API (org.apache.geode.internal.JarDeployer#deploy(java.lang.String[], byte[][])) it seems that org.apache.geode.internal.ClassPathLoader#classLoaderForDeployedJars is getting overwritten with every deploy attempt. Hence it is not possible to invoke this internal API in user application multiple times to load different jars and classloader to GEODE classPathLoader on the fly.
3. For dynamic plugging of jar it is enough just to add corresponding classLoader to Geode ClassPathLoader, hence required classes will be loaded once needed and it is not necessary to have another copy of that JAR in deployment directory, keep versioning of that and afterwards take care of undeploying it to release consumed resources.

So we think that giving some API to user that will allow to dynamically load/unload specific ClassLoader to ClassPathLoader will address this issue. Could anyone please kindly share his thoughts on this?

Thanks,
Vahram

Re: Add custom ClassLoaders to Geode after startup

[Jens Deppe <je...@apache.org>]

Hi Vahram,

I'm not entirely clear what your use case is. Are you asking for an
official java API which mimics the "gfsh deploy command"?

--Jens


On Wed, Oct 25, 2017 at 5:54 AM, Vahram Aharonyan <va...@vmware.com>
wrote:

> Hi,
>
>
>
> Currently we are facing issues with letting Geode to know about our java
> plugins that are being loaded on distributed system members during runtime.
>
> Jira story about this is opened by us recently - GEODE-3904.
>
> Just posting here to understand if others have hit this kind of issue or
> to have additional thoughts that can help us addressing this issue.
>
>
>
> Specifically, our issue occurs when we try to perform some action that
> causes serialization/deserialization of objects that are instance of
> classes coming from plugin JARs. To successfully complete these operations
> Geode need to have this plugin jars/classLoaders in its ClassPathLoader.
>
>
>
> In Geode versions prior to 1.2.0 it was possible to achieve this goal by
> invoking internal ClassPathLoader#addOrReplaceAndSetLatest API. This
> piece of code was removed in 1.2.0 as a part of ClassPathLoader changes to
> rely on single URLClassLoader. After this change alternate way to update
> Geode class loaders is to deploy plugin Jar but this does not seem to be
> possible due to the following:
>
>
>
> 1. Per documentation, clean way for user to deploy a JAR is only with
> usage of gfsh. There is no public API that allows user programs to perform
> JAR deployment runtime once cluster/member startup is already finished.
>
> 2. With usage of internal API (org.apache.geode.internal.
> JarDeployer#deploy(java.lang.String[], byte[][])) it seems that
> org.apache.geode.internal.ClassPathLoader#classLoaderForDeployedJars is
> getting overwritten with every deploy attempt. Hence it is not possible to
> invoke this internal API in user application multiple times to load
> different jars and classloader to GEODE classPathLoader on the fly.
>
> 3. For dynamic plugging of jar it is enough just to add corresponding
> classLoader to Geode ClassPathLoader, hence required classes will be loaded
> once needed and it is not necessary to have another copy of that JAR in
> deployment directory, keep versioning of that and afterwards take care of
> undeploying it to release consumed resources.
>
>
>
> So we think that giving some API to user that will allow to dynamically
> load/unload specific ClassLoader to ClassPathLoader will address this
> issue. Could anyone please kindly share his thoughts on this?
>
>
>
> Thanks,
>
> Vahram
>