Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
Date: Thu, 1 Jun 2017 09:46:36 -0700 (PDT)
From: npordash <nickpordash@gmail.com>
To: dev@ignite.apache.org
Message-ID: <1496335596240-18358.post@n4.nabble.com>
In-Reply-To: <1494004881185-17524.post@n4.nabble.com>
References: <0F949E61-E06A-4105-8086-BEE194D84B1E@apache.org> <CABuYRcrkFvGM04qfuc=puXQ4Oozuji_cbYTPmsy-q2WHh2Ghuw@mail.gmail.com> <925B4E5F-BF0E-4A34-9DD9-BC7F40B84034@apache.org> <1493149373391-17221.post@n4.nabble.com> <CAMegbcJ8C2WLpn8V74TuVm+0rjbwvtPTbZZ_Mb=8NqFhXD3QJg@mail.gmail.com> <1493162622715-17224.post@n4.nabble.com> <A4CBF8F4-309C-453C-ABFD-2389805A80BA@apache.org> <1493422509590-17339.post@n4.nabble.com> <3E8652DB-02C7-4C8F-90AD-B0BF7C777381@apache.org> <1494004881185-17524.post@n4.nabble.com>
Subject: Re: BinaryObjectImpl.deserializeValue with specific ClassLoader
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
archived-at: Thu, 01 Jun 2017 17:01:27 -0000

I wanted to provide an update on where I am at with this as I'm still
exploring different options.

For the time being I've taken the path of using a delegating ClassLoader in
IgniteConfiguration as was previously suggested; however, with the
difference being that whenever a service is deployed/undeployed I end up
replacing the ClassLoader with a new instance that has the service's
ClassLoader added/removed. The replacement is necessary so that unused/old
classes can be reclaimed by the garbage collector and that new versions can
be deployed in the future.

Overall I think this is a more comprehensive approach since it also allows
execution constructs like CacheEntryProcessor implementations provided by
the service to be used across the grid without enabling p2p classloading
(assuming the service is deployed to every node).

There are a few concerns/issues with this approach:

1) There are still isolation concerns with class versions across different
services, but as long as the services don't have dependencies between each
other or have overlapping class usage in a cache or execution context then
it's a non-issue.
2) Using OnheapCacheEnabled in conjunction with service provided domain
classes is impossible since once the service is reloaded and we get a new
classloader all calls to deserialize will fail.
3) This approach only works if nothing caches the result of
IgniteConfiguration.getClassLoader, which isn't obvious since the docs
related to classloader behavior in Ignite is pretty sparse (or at least I
could not find it). I don't think anything does when I check that method
usage, but I'm not 100% sure about that.


--
View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-tp17126p18358.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.