river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: [Discuss] Lookup Service - was Drop support for Activation?
Date Tue, 17 Nov 2015 20:47:17 GMT
Yes, so what I'm considering is, should this functionality be part of proxy preparation.  Or
should I just focus on security and delaying unmarshalling until after filtering and successful



Sent from my Samsung device.
  Include original message
---- Original message ----
From: Gregg Wonderly <gergg@cox.net>
Sent: 18/11/2015 05:03:22 am
To: dev@river.apache.org
Subject: Re: [Discuss] Lookup Service - was Drop support for Activation?

Sent from my iPhone 

> On Nov 16, 2015, at 5:01 AM, Peter <jini@zeus.net.au> wrote: 
> 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.

Idempotent services and a simple proxy wrapper make this pretty easy to do.  And with a dynamic, reflection based mechanism, you can create the local wrapper proxy with the lookup details, and it can dynamically rediscover on lease driven losses and your calls through the proxy can almost happen without interruption.


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