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 <mailto:j...@zeus.net.au>
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 <mailto:da...@travellinck.com>
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 <mailto:j...@zeus.net.au>
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 [3.622s]
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
------------------------------------------------------------------------
