river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gregg...@gmail.com>
Subject Re: [Discuss] Drop support for Activation?
Date Mon, 16 Nov 2015 03:47:16 GMT

> On Nov 13, 2015, at 10:36 PM, Peter <jini@zeus.net.au> wrote:
> 
> comment inline, sorry this phone doesn't quote your message
> 
> Sent from my Samsung device.
>   Include original message
> ---- Original message ----
> From: Greg Trasuk <trasukg@stratuscom.com>
> Sent: 14/11/2015 12:01:12 pm
> To: dev@river.apache.org
> Subject: Re: [Discuss] Drop support for Activation?
> 
> 
>>  On Nov 13, 2015, at 6:53 PM, Peter <jini@zeus.net.au> wrote: 
>>   
>>  On long lived Objects: 
>>   
>>  one of the design issues with the lookup service is the codebase annotation and
 
>>  proxy are uploaded and stored.  unfortunately these can change over time, and codebase
annotations can be lost. 
> 
> I’m confused here - why would the proxy or codebase annotation change on a service
that is alive, without the service informing the registrar?  The only case where that would
happen is if the service dies and a new one starts up.  In that case, either the new service
would re-use the original serviceID, hence overwrite the original registration, or the lease
on the original registration should expire in a reasonable time, causing the original registration
to be dropped. 
> 
> REPLY:
> 
>  There is no mechanism to notify the client that the proxy or codebase has been updated.
 Although you are correct that the registrar should have a marshalled instance of the latest
proxy.  We could say failure is the mechhanism used to cause the client to rediscover a replacement,
but partial failure and releasing resources can be problematic.
> 

Lease cancellation and/or lease expiry notifies the client.  That’s what should cause the
client to rediscover shouldn’t it?

> 
>>   
>>  When i was investigating security, I looked into Reggie only storing a bootstrap
proxy (local code only) which solves a number of problems: 
>>   
>>  1. No unnecessary codebase downloads. 
>>  2. codebase annotation and proxy obtained directly from service, is always current.

>>  3. long lived objects could be wrapped and refreshed using the bootstrap proxy.

>>  4. codebase and proxy download occurs after authentication. 
>>   
> 
> A service implementation could certainly take the bootstrap proxy approach as an implementation
practice.  Shouldn’t really affect Reggie either way.  Reggie does not load the registered
proxies, hence it has no reason to download any remote code.  This is one huge advantage that
Reggie has over rmid - it’s clients can evolve without requiring a Reggie restart. 
> 
> REPLY;
> 
> What about Reggie's client side proxy?  It's implementation causes proxy's to be unmarshalled
and codebases to be downloaded prior to client side authentication and filtering?

The basic issue from my perspective is that we still have not chosen to separate lookup, entry
inspection and unmarshalling into three different actions, which they really should be.  I
made this a part of my changes to reggie with my new APIs a long time ago.  It really does
keep your VM from exploding because of lookup unmarshalling, and it allows you to look at
Entry values so that a client “browser” or “desktop”, can get details about a service
without having to unmarshal the proxies and undergo all the downloading needed to just get
Entry values, which are largely going to be locally resolvable classes.  My changes to provide
a “never preferred”, platform defining mechanism further simplifies and reinforces the
opportunity of secured code.

> 
> 
>>  Another issue we have is with the Entry specification, it doesn't allow Entry classes
to evolve without breakage, it is far less flexible than Serializable objects for example.
 This has implications for Javaspaces, occasionally we have developers with deployments who
have discovered this the hard way. 
>>   
>>  Breaking changes in Entry objects: 
>>  1. Changing the order of fields. 
>>  2. Changing the name of a field. 
>>  3. Adding a field to a parent class breaks all subclasses. 
>>  4. Changing a fields type. 
>>   
>>  We could update the entry spec to address these issues. 
> 
> Is it reasonable to evolve Entry objects?  If they’re a communications mechanism, does
it make sense that an Entry producer and an Entry consumer should have different ideas of
what’s in a given Entry type?   
> 
> Not to mention, the Outrigger implementation does all the marshalling and unmarshalling
of Entry objects in the SpaceProxy, i.e. on the client (to Outrigger) side.  Outrigger itself
never loads the classes.  So it would seem that evolution of Entrys is not Outrigger’s concern
- it’s between the users of the Space.  Similarly Reggie marshalls Entrys on the client
side 
> 
> REPLY:
> 
> I  think so, it would be better if it was possible to handle some forms of evolution
to make life easier for developers.

One should always be able to subclass an Entry and add values into the new Entry.  Extending
an existing namespace without a new class definition will be problematic in any two way exchange
of Entry object data.

Gregg

> 
> 
>>  
>>  Regards, 
>>   
>>  Peter. 
>>   
>>  Sent from my Samsung device. 
>>    Include original message 
>>  ---- Original message ---- 
>>  From: Bryan Thompson <bryan@systap.com> 
>>  Sent: 14/11/2015 06:34:11 am 
>>  To: user@river.apache.org 
>>  Cc: <dev@river.apache.org> <dev@river.apache.org> 
>>  Subject: Re: [Discuss] Drop support for Activation? 
>>   
>>  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
View raw message