ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: BinaryObjectImpl.deserializeValue with specific ClassLoader
Date Fri, 28 Apr 2017 03:01:44 GMT

Internally, binary marshaller supports as many class loaders as needed. Even more, it can
store different versions of the same class loaded by different loaders. It’s a responsibility
of an Ignite component to pass a valid class loader to it at deserialization time. 

The cache component simply passes IgniteConfiguration.getClassLoader() all the times. If that
class loader is not, meaning the marshaller will received ’null’ as a class loader value
then it will use the system class loader.

Here is on of the places in the caching internals that triggers an object deserialization

private BinaryReaderExImpl reader(@Nullable BinaryReaderHandles rCtx, boolean forUnmarshal)
    BinaryOffheapInputStream stream = new BinaryOffheapInputStream(ptr, size, false);


    return new BinaryReaderExImpl(ctx,

As an idea, what if you create your custom class loader that will offload to a context class
loader whenever is needed. Do you think it will work for you?

> On Apr 25, 2017, at 4:23 PM, npordash <nickpordash@gmail.com> wrote:
> Hi Alexei,
> I believe the problem with that approach is that I won't be able to reload
> classes because there is a single classloader that Ignite is referencing.
> When I undeploy a service I also want to allow the corresponding classloader
> (there is 1 per service) and classes to get reclaimed by the JVM (if it
> choses to do so, of course).
> It would also prevent multiple versions of the same class from being used.
> If I have two services deployed then I don't want classes from service 1 to
> get resolved by service 2 simply because service 1 was there first and a
> class with the same name was already resolved by the delegating classloader.
> It's entirely possible the version of the class files are different and this
> would lead to some interesting and confusing errors. 
> This is why I was suggesting to refer to the thread context classloader
> during deserialization because it doesn't impact your API and it addresses
> all of the above issues. However, I can't get a feel for the behavioral
> impact of this change by simply looking at the Ignite codebase and I'm not
> sure what the rationale was to restrict classloading to Ignite's
> classloader.
> -Nick
> --
> View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-tp17126p17224.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message