river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: OSGi - deserialization remote invocation strategy
Date Wed, 08 Feb 2017 03:18:46 GMT

> On Feb 7, 2017, at 8:56 AM, Michał Kłeczek (XPro Sp. z o. o.) <michal.kleczek@xpro.biz>
wrote:
> 
> Comments inline
> 
> Niclas Hedhman wrote:
>> 4. For Server(osgi)+Client(osgi), number of options goes up. In this space,
>> Paremus has a lot of experience, and perhaps willing to share a bit,
>> without compromising the secret sauce? Either way, Michal's talk about
>> "wiring" becomes important and that wiring should possibly be
>> re-established on the client side. The insistence on "must be exactly the
>> same version" is to me a reflection of "we haven't cared about version
>> management before", and I think it may not be in the best interest to load
>> many nearly identical bundles just because they are a little off, say stuff
>> like guava, commons-xyz, slf4j and many more common dependencies.
> This problem is generally unsolvable because there are contradicting requirements here:
> 1. The need to transfer object graphs of (unknown) classes
> 2. The need to optimize the number of class versions (and the number of ClassLoaders)
in the JVM
> 
> It might be tempting to do the resolution on the client but it is (AFAIR) NP-hard
> - the object graph is a set of constraints on possible module (bundle) versions. Plus
there is a whole
> set of constraints originating from the modules installed in the container prior to graph
deserialization.
> 
> So the only good solution for a library is to provide a client with an interface to implement:
> Module resolve(Module candidate) (or Module[] resolve(Module[] candidates))
> and let it decide what to do.
> 
>> 
>> Peter wrote;
>>> This is why the bundle must be given first
>>> attempt to resolve an objects class and rely on the bundle dependency
>> resolution process.
>>> OSGi must be allowed to wire up dependencies, we must avoid attempting to
>> make decisions about
>>> compatibility and use the current bundle wires instead (our stack).
>> 
>> Well, not totally sure about that. The 'root object classloader' doesn't
>> have visibility to serialized objects, and will fail if left to do it all
>> by itself. And as soon as you delegate to another BundleClassLoader, you
>> have made the resolution decision, not the framework. Michal's proposal to
>> transfer the BundleWiring (available in runtime) from the server to the
>> client, makes it somewhat possible to do the delegation. And to make
>> matters worse, it is quite common that packages are exported from more than
>> one bundle, so the question is what is included in the bundleWiring coming
>> across the wire.
> The whole issue with proposals based on the stream itself is the fact that to resolve
properly
> one have to walk the whole graph first to gather all modules and their dependencies.
> 
> It is much better to simply provide the module graph (wiring) first (at the beginning
of the stream)
> and only after resolution of all the modules - deserialize the objects.

The missing notion of versioning in classloader was meant to be solved by URLs in the annotations.
 That would provide explicit versioning control and through the use of the TCCL, code and
objects could be isolated from other versions.  However, that’s not perfect, and so the
preferred class loading mechanism is also a path that allows a “platform” or “hosting”
environment to declare the classes that it will use to  interact with a client/proxy.

Practically, it’s exactly the NP-hard problem you say though.  There are “pretty good”
solutions, but realistically there is not a perfect solution until there is an exact dependency
graph which allows perfect specification of dependencies.

Gregg

> 
> Thanks,
> Michal


Mime
View raw message