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 23:38:52 GMT
Ok, I understand.

Have a look in our email archives around April 2013.

Although I put in a considerable effort, I personally, wasn't able / capable to determine
"which" race conditions or unsafe publications were causing  test failures.

The failures were random and went away when I tried to observe them. In a real system, incorrect
state caused by dropped events will eventually be corrected by later events.

I don't have the hardware that exposed these failures that confirmed my fixes anymore.  Race
conditions may or may not be evident after reverting changes.

Fixing race conditions in River eventually became a very contentious issue, I'd rather focus
my efforts on new functionality, but I'll help out anyone brave enough to take it on. :)

It may be easier to to debug race conditions now, given a lot of other issues have been fixed.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
---- Original message ----
From: Patricia Shanahan <pats@acm.org>
Sent: 26/04/2016 08:50:08 am
To: dev@river.apache.org
Subject: Re: River 3.0 API changes

My initial feeling is in favor of reverting - if we have test failures,  
we should investigate whether the bug is in River or in the test. If it  
is in the test, fix the test. 

I have been trying to think whether there is a simple way of finding and  
reviewing suspect tests. Presumably a test would have to be affected by  
the changes to have a bug that is fixed by them? 

Patricia 

On 4/25/2016 3:46 PM, Peter wrote: 
> 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