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.klec...@xpro.biz> Sent: 15/11/2016 10:30:29 pm To: dev@river.apache.org 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 ------------------------------------------------------------------------
