river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject River 3.0 API changes
Date Mon, 25 Apr 2016 10:58:29 GMT
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 & 
net.jini.core.lookup.ServiceEvent - protected fields changed to final 
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.



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 
                 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 
                 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 
                 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 
                 upon renewal a new set with successfully renewed leases
                 would be returned.

View raw message