river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: River 3.0 API changes
Date Mon, 25 Apr 2016 22:46:28 GMT
If I don't receive any responses, I'll revert these changes, prior to publishing the River
3.0 release artifacts next week end.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
---- Original message ----
From: Peter <jini@zeus.net.au>
Sent: 25/04/2016 09:23:16 pm
To: dev@river.apache.org
Subject: Re: River 3.0 API changes

Correction: 

net.jini.core.discovery.LookupLocator (incorrect package listed below),  
also has two protected fields that have been made final, host and port. 

Regards, 

Peter. 

On 25/04/2016 8:58 PM, Peter wrote: 
> Before we release River 3.0, I think it's important to discuss changes 

> to the public api. 
> 
> Changes to api have been minimal, however we should come to concensus  
> prior to release.  Note that changes made were for correctness reasons 

> only, but the community should decide whether we should favour  
> correctness or backward compatibility. 
> 
> The changes: 
> 
> net.jini.core.event.RemoteEvent - protected fields changed to final &  
> private. 
> net.jini.core.lookup.ServiceEvent - protected fields changed to final  
> protected. 
> net.jini.discovery.RemoteDiscoveryEvent - protected field discarded  
> changed to final protected, protected fields; marshalledRegs, regs &  
> groups changed to private final. 
> 
> Note that net.jini.lookup.LookupLocator's serial from changed in River  
> 2.2, in a non backward compatible way, however the LookupLocator in  
> River 3.0 doesn't include the change, but it's serial form is backward 

> compatible with both versions (at some point I'd like to address the  
> issue that change intended to address). 
> 
> In all cases serial form has been preserved. 
> 
> These changes were made at the same time the new Startable.start()  
> interface was created, that didn't go down too well, I didn't get  
> around to discussing the above changes after the fallout from that. 
> 
> Prior to making a decision, I'd like to discuss why the changes were  
> made, examples of impacts it will have on downstream code, including  
> what's updates are required.  Keep in mind that people will need to  
> recompile River 3.0 due to namespace changes, so this should be based  
> on whether the changes required can be done so without impacting  
> client code backward compatibiliy. 
> 
> I'm not against reverting these changes, however we need to understand  
> that doing so will result in dropped events in tests, caused by unsafe 

> publication, causing some test failures.  River 3.0 has far less  
> blocking than the 2.2 branch, this exposes race conditions. 
> 
> It's worth noting I haven't fixed all race conditions in River 3.0,  
> but I have fixed the majority. 
> 
> Regards, 
> 
> Peter. 
> 
> What I would have liked to fix but didn't (I did manage to work around 

> it), a fundamental design issue with lease identity is, an expired  
> lease is equal to a current lease, if both leases have the same id,  
> when really the renew method should return a new lease with the same  
> lease id, that isn't equal,  in my mind LeaseMap should have also been 

> immutable, with a new map containing renewed leases returned upon  
> renewal: 
> 
> Sun Bug: 4287125 
>         Norm: Client leases are being renewed after the set they are 

> in should 
>                 have expired. 
> 
>                 A given client lease should not be renewed after the 

> set it is in 
>                 has expired.  An iron-clad guarantee can't be made 

> here because 
>                 we can't hold onto locks while leases are being 

> renewed.  However, 
>                 the problem with Norm was worse than could be 

> explained by the 
>                 short window between committing to renew a client 

> lease and 
>                 performing the actual renewal.  The problem arose because

>                 there was no check in the renewal threads to make sure 

> that 
>                 the set the client lease was in still current, and 

> because the 
>                 thread that removed sets from the service often runs 

> late.  Such 
>                 a check is now performed so the window where a client 

> lease renewal 
>                 can occur, after the lease on the set the client lease 

> is in has 
>                 expired, is very small. 
> 
>                 Comment by P. Firmstone Apr 21st 2016: <br>

>                 These issues would not occur with immutable leases and 

> sets, 
>                 upon renewal a new set with successfully renewed leases

>                 would be returned 
> 
> 



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