Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Message-ID: <5649B78C.3050301@zeus.net.au>
Date: Mon, 16 Nov 2015 21:01:32 +1000
From: Peter <jini@zeus.net.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
 rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: [Discuss] Lookup Service - was Drop support for Activation?
References: <bb1b449088c6e237ed0aced417fc1fb4@org.tizen.email>
 <1C4541E2-F400-4714-86A6-B82F35E303EF@wonderly.org>
In-Reply-To: <1C4541E2-F400-4714-86A6-B82F35E303EF@wonderly.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 16/11/2015 1:47 PM, Gregg Wonderly wrote:
>> 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?

Right, currently the client needs to wrap the proxy's it receives and 
look them up again after cancellation.

>>>
>>>   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.

I agree with everything you're saying here.  In addition, allowing 
proxy's to be unmarshalled by the lookup service, denies the client the 
ability to authenticate first.  I believe it is the proxy preparer that 
should perform unmarshalling, but only after Entry's have been filtered 
and the service authenticated.

Currently the lookup service stores proxy's in Marshalled form.  A 
bootstrap proxy is local code, hence no download, so we can achieve what 
you have, with the existing api, without changing client code, only the 
platform and configuration (ignoring for the moment security issues with 
serialization).  The real proxy can be obtained from the bootstrap 
proxy, rather than vice versa, after authentication, this can be done 
using proxy preparation, while retaining the existing lookup service 
api.  In addition, the proxy can be wrapped with a local delegate that 
manages the proxy's lifecyle, replacing the implementation as necessary, 
also when the proxy is transferred around nodes in a network, only the 
bootstrap proxy and encapsulating delegate is sent, thus authentication 
can occur and codebase annotations preserved prior to codebase and proxy 
downloads.

Such a mechanism might also allow the proxy to be downloaded into a 
subprocess jvm, in its own namespace, again without changing client 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.

I agree, an Entry is like an interface, but developers usually find out 
the hard way.

Perhaps we can document it better?  I had thought that loss of data was 
better than breakage, but then perhaps not.

Cheers,

Peter.