river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Maven Build
Date Wed, 16 Nov 2016 08:11:34 GMT
I am curious, what do you mean by "non-deterministic dependency resolution"
?  You can make it as predictable as you wish with attributes and
directives.

Cheers
Niclas

On Wed, Nov 16, 2016 at 4:07 PM, Michał Kłeczek <michal.kleczek@xpro.biz>
wrote:

> While non-hierarchical class loading is crucial, OSGI with its
> non-deterministic dependency resolution is very difficult ( if not
> impossible ) to target.
> I'm working on JBoss Module based class loading for River which I'm going
> to propose as contribution soon.
>
> Thanks,
> Michal
>
> On Wednesday, 16 November 2016, Dawid Loubser <dawid@travellinck.com>
> wrote:
>
> > +1 for OSGi providing the best solution to the class resolution problem,
> > though I think some work will have to be done around trust, as you say.
> >
> >
> > On 16/11/2016 02:23, Peter wrote:
> > >
> > > The conventional alternatives will remain;  the existing ClassLoader
> > isolation and the complexities surrounding multiple copies of the same or
> > different versions of the same classes interacting within the same jvm.
> > Maven will present a new alternative of maximum sharing, where different
> > service principals will share the same identity.
> > >
> > > Clearly, the simplest solution is to avoid code download and only use
> > reflection proxy's
> > >
> > > An inter process call isn't remote, but there is a question of how a
> > reflection proxy should behave when a subprocess is terminated.
> > >
> > > UndeclaredThrowableException seems appropriate.
> > >
> > > It would plug in via the existing ClassLoading RMIClassLoader provider
> > mechanism, it would be a client concern, transparent to the service or
> > server.
> > >
> > > The existing behaviour would remain default.
> > >
> > > So there can be multiple class resolution options:
> > >
> > > 1. Existing PrefferedClassProvider.
> > > 2. Maven class resolution, where maximum class sharing exists.  This
> may
> > be preferable in situations where there is one domain of trust, eg within
> > one corporation or company.  Max performance.
> > > 3. Process Isolation.  Interoperation between trusted entities, where
> > code version incompatibilities may exist, because of separate development
> > teams and administrators.  Each domain of trust has it's own process
> > domain.  Max compatibility, but slower.
> > > 4. OSGi.
> > >
> > > There may be occassions where simpler (because developers don't need to
> > understand ClassLoaders), slow, compatible and reliable wins over fast
> and
> > complex or broken.
> > >
> > > A subprocess may host numerous proxy's and codebases from one principal
> > trust domain (even a later version of River could be provisioned using
> > Maven).  A subprocess would exist for each trust domain. So if there are
> > two companies, code from each remains isolated and communicates only
> using
> > common api.  No unintended code versioning conflicts.
> > >
> > > This choice would not prevent or exclude other methods of
> communication,
> > the service, even if isolated within it's own process will still
> > communicate remotely over the network using JERI, JSON etc.  This is
> > orthogonal to and independant of remote communication protocols.
> > >
> > > OSGi would of course be an alternative option, if one wished to execute
> > incompatible versions of libraries etc within one process, but different
> > trust domains will have a shared identity, again this may not matter
> > depending on the use case.
> > >
> > > Cheers,
> > >
> > > Peter.
> > >
> > > ESent from my Samsung device.
> > >
> > >   Include original message
> > > ---- Original message ----
> > > From: "Michał Kłeczek (XPro Sp. z o. o.)" <michal.kleczek@xpro.biz
> > <javascript:;>>
> > > Sent: 15/11/2016 10:30:29 pm
> > > To: dev@river.apache.org <javascript:;>
> > > Subject: Re: Maven Build
> > >
> > > While I also thought about out-of-process based mechanism for execution
> > of dynamically downloaded code, I came to the conclusion that in the
> > context of River/Java in-process mechanism is something that MUST be done
> > right. All other things can (and should) be built on that.
> > >
> > > I think that the proposal to implement "remote calls on smart proxy
> > interfaces that aren't remote" is somewhat a misnomer. The call is either
> > remote or local - you cannot have both at the same time. AFAIK Jini
> > community always believed there is no possibility to have local/remote
> > transparency. That is why there exists java.rmi.Remote marker interface
> in
> > the first place.
> > >
> > > There is also the question about the level of isolation you want to
> > achieve. Simple "out-of-process" is not enough, chroot is not enough,
> > CGROUPS/containers/jails/zones might be not enough, virtual machines
> might
> > be not enough :) - going the route you propose opens up the whole world
> of
> > new questions to answer. At the same time you loose the most important
> > advantages of in-process execution:
> > > - simplicity of communication between components (basic function call,
> > no need to do anything complicated to implement callbacks etc.)
> > > - performance
> > >
> > > In the end you either standardize on the well known set of
> communication
> > protocols (such as JERI) OR you say "end of protocols" by allowing
> > execution of dynamically downloaded code in-process.
> > > If River is going to choose the first route - IMHO it is going to fail
> > since it does not propose anything competitive comparing to current
> > mainstream HTTP(S)/REST/JSON stack.
> > >
> > > Thanks,
> > > Michal
> > > Peter November 15, 2016 at 8:28 AM
> > > I've been thinking about process isolation (instead of using
> > ClassLoader's for isolation).  Typically, smart proxy's are isolated in
> > their own ClassLoader, with their own copies of classes, however with
> > Maven, a lot more class sharing occurs.  Since River uses codebase
> > annotations for identity, using maven codebase annotations will result in
> > proxy's from different services sharing identity.
> > >
> > > A better way to provide for different identities coexisting on the same
> > node, would be to use subprocess jvm's for each Service's server
> principal
> > identity, to keep classes from different services in different processes.
> > >
> > > This way, each principal would have their own process & Maven namespace
> > for their proxy's.
> > >
> > > Presently JERI only exports interfaces in reflection proxy's that
> > implement Remote, so I'd need an endpoint that can export all
> interfaces,
> > accross a local interprocess connection to allow remote calls on smart
> > proxy interfaces that aren't remote.
> > >
> > > This also means that memory resource consumption of smart proxy's can
> be
> > controlled by the client and a smart proxy's process killed without
> killing
> > the client jvm.
> > >
> > > Cheers,
> > >
> > > Peter.
> > >
> > >
> > >
> > > Dawid Loubser November 15, 2016 at 8:50 AM
> > > As a very heavy Maven user, I wanted to say that this is great news.
> > > This is encouraging indeed!
> > >
> > > Dawid
> > >
> > >
> > > Peter November 15, 2016 at 4:08 AM
> > > Some other news that might  encourage participation, I've been working
> > on Dennis Reedy's script to modularise the codebase, I haven't run the
> test
> > suites against it and it isn't generating stubs yet, and I'll need to
> > modify the platform modules for the IoT effort after the conversion is
> > complete.
> > >
> > > Here's the output of the River maven build:
> > >
> > > Reactor Summary:
> > >
> > > River-Internet Project ............................ SUCCESS [0.689s]
> > > Module :: River Policy ............................ SUCCESS [8.395s]
> > > Module :: River Resources ......................... SUCCESS [0.607s]
> > > Module :: River Platform .......................... SUCCESS  [23.521s]
> > > Module :: River Service DL Library ................ SUCCESS [8.999s]
> > > Module :: River Service Library ................... SUCCESS [8.014s]
> > > Module :: River Service Starter ................... SUCCESS [3.930s]
> > > Module :: River SharedGroup Destroy ............... SUCCESS [3.018s]
> > > Module :: Outrigger .............................. SUCCESS [0.056s]
> > > Module :: Outrigger Service Download classes ...... SUCCESS [2.416s]
> > > Module :: Outrigger Service Implementation ........ SUCCESS [4.118s]
> > > Module :: Outrigger Snaplogstore ................. SUCCESS [3.273s]
> > > Module :: Lookup Service ......................... SUCCESS [0.048s]
> > > Module :: Reggie Service Download classes ........ SUCCESS [3.966s]
> > > Module :: Reggie Service Implementation .......... SUCCESS [3.621s]
> > > Module :: Mahalo ................................. SUCCESS [0.436s]
> > > Module :: Mahalo Service Download classes ......... SUCCESS [2.059s]
> > > Module :: Mahalo Service Implementation ........... SUCCESS [4.175s]
> > > Module :: Mercury the Event Mailbox ............... SUCCESS [0.497s]
> > > Module :: Mercury Service Download classes ........ SUCCESS [3622s]
> > > Module :: Mercury Service Implementation .......... SUCCESS [3.562s]
> > > Module :: Norm .................................... SUCCESS [0.013s]
> > > Module :: Norm Service Download classes ........... SUCCESS [2.867s]
> > > Module :: Norm Service Implementation ............. SUCCESS [6.390s]
> > > Module :: Group ................................... SUCCESS [0.025s]
> > > Module :: Mahalo Service Download classes ......... SUCCESS [2.877s]
> > > Module :: Group Service Implementation ............ SUCCESS [2.037s]
> > > Module :: Tools ................................... SUCCESS [0.485s]
> > > Module :: Check ConfigurationFile ................. SUCCESS [2.720s]
> > > Module :: Check serialversionUid .................. SUCCESS [2.129s]
> > > Module :: ClassDep ................................ SUCCESS [4.157s]
> > > Module :: Class Server ............................. SUCCESS [3.353s]
> > > Module :: Compute message digest .................. SUCCESS [1.734s]
> > > Module :: Compute httpmd codebase ................. SUCCESS [2.102s]
> > > Module :: Environment Check ...................... SUCCESS [2.837s]
> > > Module :: Jar wrapper ............................ SUCCESS [2.179s]
> > > Module :: Preferred classes list generator ........ SUCCESS [2.495s]
> > > Module :: Phoenix Activation ..................... SUCCESS [0.029s]
> > > Module :: Phoenix Download ....................... SUCCESS [2.685s]
> > > Module :: Phoenix ................................ SUCCESS [4.095s]
> > > Module :: Phoenix Group ........................... SUCCESS [2.445s]
> > > Module :: Phoenix Init ............................ SUCCESS [1.740s]
> > > River Distribution ................................ SUCCESS [10.523s]
> > > ------------------------------------------------------------
> ------------
> > > BUILD SUCCESS
> > > ------------------------------------------------------------
> ------------
> > > Total time: 2:29.804s
> > > Finished at: Mon Nov 14 22:22:31 EST 2016
> > > Final Memory: 145M/247M
> > > ------------------------------------------------------------
> ------------
> > >
> > >
> > >
> > >
> >
> >
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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