Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <1496335596240-18358.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> <1496335596240-18358.post@n4.nabble.com>
From: Valentin Kulichenko <valentin.kulichenko@gmail.com>
Date: Wed, 7 Jun 2017 16:27:54 -0700
Message-ID: <CABuYRcqw0SpS9E4_Wx8_ry9X=Ax__ER3jp=jfQrGxcW1OwaRgw@mail.gmail.com>
Subject: Re: BinaryObjectImpl.deserializeValue with specific ClassLoader
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="001a114a9e74b1a59705516717bc"
archived-at: Wed, 07 Jun 2017 23:28:30 -0000

--001a114a9e74b1a59705516717bc
Content-Type: text/plain; charset="UTF-8"

Hi Nick,

How exactly do you replace the class loader and can you give a little bit
more detail about why you do this?

As for the issues, here are my comments:

   1. Can you clarify this? In which scenario it doesn't work and why?
   2. Why do you deploy domain classes in the first place? Ignite
   architecture assumes that there are no classes on server side at all, so I
   think it would be very hard to load them dynamically. Can you use binary
   objects instead?
   3. I can't recall any such places from the top of my head, but frankly I
   don't think you have such a guarantee. IgniteConfiguration object is
   assumed to be created prior to node startup. It should not be modified
   after startup.

-Val

On Thu, Jun 1, 2017 at 9:46 AM, npordash <nickpordash@gmail.com> wrote:

> 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.
>

--001a114a9e74b1a59705516717bc--