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 <p...@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 <j...@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 >> >> > > >
