river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
Subject Re: OSGi - deserialization remote invocation strategy
Date Tue, 07 Feb 2017 14:56:10 GMT
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.

Thanks,
Michal

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