Sounds just like the overhead of object relational mappers. Fine for one object. Death if you are trying to chase object graphs.... On Nov 13, 2015 3:11 PM, "Greg Trasuk" <tras...@stratuscom.com> wrote:
> > > On Nov 13, 2015, at 2:21 PM, Bryan Thompson <br...@systap.com> wrote: > > > > I was trying to remember precisely what is in "activation". I found this > > [1]. From [1]: > > > > "Distributed object systems are designed to support long-lived persistent > > objects. Given that these systems will be made up of many thousands > > (perhaps millions) of such objects, it would be unreasonable for object > > implementations to become active and remain active, taking up valuable > > system resources for indefinite periods of time. In addition, clients > need > > the ability to store persistent references to objects so that > communication > > among objects can be re-established after a system crash, since > typically a > > reference to a distributed object is valid only while the object is > active." > > > > So the concept here was long lived object references and robustness of > > those references. > > > > This all seems very appropriate for IoT, but perhaps the goal of such > > durable / robust / on demand (re-)activation of services is now met > through > > other mechanisms? Something that does not need to be part of River? > > > > “Long-lived persistent objects” reminds me of the Entity EJBs in EJB 1 and > 2. The metaphor there was that every entity (e.g. a User) was represented > by a persistent object, identified by a primary key, and you interacted > with the entity by making remote method calls on the entity’s proxy. The > problem was that the typical interaction would be ‘getName()’, > ‘getEmail()’, 'getUserId()’, ‘getPhoneNumber()’, etc. By the time you had > any useful interaction you might have made 10-15 remote method calls. Put > twenty entities on a web page, and you might need to make hundreds of > remote calls to display the page. In other words, the distributed objects > were at the wrong level of granularity. > > If we have distributed services, on the other hand, we can readily > accommodate the right granularity in the service design. In that case, > though, activation only makes sense if we have so many services that it > isn’t practical to keep them all alive at the same time. Typically you > have a reasonable number of services in any given virtual machine > instance. I suspect that if you really did have that many services that > needed activation, you’d end up with a really slow system because the > overhead of activating and passivating services would far outweigh the time > spend in actual service calls. > > So, I don’t see much of a use case for Activation. I’m interested to see > if anyone else does. > > Cheers, > > Greg Trasuk > > > Thanks, > > Bryan > > > > [1] > > > http://www.javaworld.com/article/2076173/soa/activatable-jini-services--part-1--implement-rmi-activation.html > > > > ---- > > Bryan Thompson > > Chief Scientist & Founder > > SYSTAP, LLC > > 4501 Tower Road > > Greensboro, NC 27410 > > br...@systap.com > > http://blazegraph.com > > http://blog.blazegraph.com > > > > Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance > > graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints > > APIs. Blazegraph is now available with GPU acceleration using our > disruptive > > technology to accelerate data-parallel graph analytics and graph query. > > > > CONFIDENTIALITY NOTICE: This email and its contents and attachments are > > for the sole use of the intended recipient(s) and are confidential or > > proprietary to SYSTAP. Any unauthorized review, use, disclosure, > > dissemination or copying of this email or its contents or attachments is > > prohibited. If you have received this communication in error, please > notify > > the sender by reply email and permanently delete all copies of the email > > and its contents and attachments. > > > > On Fri, Nov 13, 2015 at 10:21 AM, Greg Trasuk <tras...@trasuk.com> > wrote: > > > >> Hello all: > >> > >> Last week I asked about removing activation from River, both the 2.2 and > >> 3.0 branches. There didn’t seem to be a lot of anti-removal feeling, so > >> I’d like to formally propose removing Activation. There are a couple of > >> other things that we could possibly remove, like JRMP support (i.e. > >> pre-compiled proxy classes), but we should probably discuss those > >> separately. > >> > >> The main reason for this is that unused code still requires maintenance > >> and increases the chance of bugs. Also I think that as we go forward > with > >> refactoring, renaming, restructuring the build and so on, it seems > wasteful > >> to do that work on code that isn’t actually in use. > >> > >> Obviously, the code remains in Subversion and in the 2.2.2 release, so > if > >> someone wants to get it back, we (or they) could package it into a > >> different deliverable. But I wouldn’t plan on doing that unless there’s > >> actual demand for it. > >> > >> My thought is to put this out there for discussion - If there is > consensus > >> after a few days I’ll call a lazy-consensus vote. I’ll be happy to do > the > >> work in the 2.2 branch. > >> > >> So, I propose to drop support for the following: > >> > >> Activation - > >> com.sun.jini.phoenix.* > >> com.sun.jini.phoenix.resources.* > >> net.jini.activation.* > >> > >> Norm / LeaseRenewalService - is pretty much unneeded without activation > >> com.sun.jini.norm.** > >> > >> Activatable implementation of the infrastructure services > >> com.sun.jini.fiddler.ActivatableFiddlerImpl > >> com.sun.jini.mahalo.ActivatableMahaloImpl > >> com.sun.jini.mercury.ActivatableMercuryImpl > >> com.sun.jini.reggie.PersistentRegistrarImpl > >> > >> Starter for Activatable Services > >> com.sun.jini.start.ActivateWrapper > >> com.sun.jini.start.SharedActivatableServiceDescriptor > >> com.sun.jini.start.SharedGroupImpl > >> > >> QA Harness classes that test any of the above. > >> > >> > >> Cheers, > >> > >> Greg Trasuk > >> > >> > >
