river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Thompson <br...@systap.com>
Subject Re: [Discuss] Drop support for Activation?
Date Fri, 13 Nov 2015 20:34:11 GMT
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" <trasukg@stratuscom.com> wrote:

>
> > On Nov 13, 2015, at 2:21 PM, Bryan Thompson <bryan@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
> > bryan@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 <trasukg@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
> >>
> >>
>
>

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