Peter,
I've been silent for a bit (lots going on for me), but suffice it to say I
don't have any issue with you going after the many issues (synchronization
based and other) that River has. For goodness sake, we're dealing with a
codebase that is 1.4 based and has many issues, you've uncovered many of them.
I just took a quick look at OutriggerServerImpl, and saw this:
1701: public long renew(Uuid cookie, long extension)
1702: throws UnknownLeaseException, LeaseDeniedException
1703: {
1704: leaseLogger.entering("OutriggerServerImpl","renew");
1705:
1706: LeasedResource resource;
1707: LeasePeriodPolicy policy;
1708:
1709: if (null != (resource = contents.getLeasedResource(cookie)))
1710: policy = entryLeasePolicy;
1711: else if (null !=
1712: (resource = (LeasedResource)eventRegistrations.get(cookie)))
1713: policy = eventLeasePolicy;
1714: else if (null !=
1715: (resource = (LeasedResource)contentsQueries.get(cookie)))
1716: policy = contentsLeasePolicy;
1717: else
1718: throw throwNewUnknownLeaseException(cookie);
1719:
1720: synchronized (resource) {
...
}
How is that exactly supposed to work? There are many cases just like this in
the codebase that need to be addressed.
Not to mention getting River up to Java 7 (at least). There is no support for
generics (I see you've at least changed Configuration to support so casting is
not required (thank god)). There are so many idioms of modern Java development
are simply not even close to being available.
So a suggestion; maybe we have the legacy branch (2.2) maintained, and River
3.0 moved forward and created from the qa_refactor branch. The new River 3.0
includes the repackaging of com.sun.jini to org.apache.river, includes the work
you've been doing (we need to at least have a list of the changes). Seems like
a nice break. Also, if the tests pass, whats the issue with the work thats been
done in qa_refactor?
BTW, I'm not particularly sold on Startable, because the interface does not
guarantee anything. A service implementation can still call start() in it's
constructor and all of the intentions of the interface are moot. Unless a
service's lifecycle can be controlled by an invoking class, you have no
guarantees.
Regards
Dennis
On Jan 21, 2014, at 840PM, Peter <j...@zeus.net.au> wrote:
> I can only give you my own thoughts and experiences, others may think
> differently.
>
> The current codebase was created through an experimental development process
> by Sun, it hadn't been compiled and tested on Java 5 until River took
> ownership. The code's now a tad on the brittle side, fixing something
> simple, often reveals unrelated latent bugs. A change in JDK version is also
> doing exactly that right now, see our windows 2008 JDK7 Jenkins build, 45
> test failures. - Don't deploy on Java 7 yet is my advise.
>
> To change the codebase to a more theory driven design, means fixing code that
> works good enough, which also causes latent bugs to manifest.
>
> Making such a transition means fixing a lot of non compliant code, or
> releasing with some failing tests and risk latent bugs manifesting during
> deployment. Out of interest, Porter (Jini 2.1) was released with some tests
> disabled, including a stress test for Outrigger, StressTestInterleaved, that
> test now passes on qa_refactor.
>
> The benefit of these changes is more robust easier to maintain and develop
> code.
>
> The risk is we might unintentionally break something.
>
> This is one of those cases, where it's easy to criticise, but hard to do.
>
> The River community has spoken with their silence on this occassion.
>
> Unless some discussion indicates otherwise, I intend to let the River
> community decide when it's ready to integrate fixes from qa_refactor and will
> no longer be looking to merge and release.
>
> For that reason, I also reccommend reverting trunk, with the exception of
> Sim's recent work, which I have peer reviewed.
>
> Regards,
>
> Peter.
>
>
> ----- Original message -----
>> Given the number of users on this mailing list, and the tiny number of
>> votes, it seems that many people are abstaining.
>> Why is this such a touchy issue?
>>
>> --
>> Dawid Loubser <da...@travellinck.com>
>>
>>
>> Op Ma, 2014-01-20 om 09:25 -0500 skryf Greg Trasuk:
>>
>>> On Jan 20, 2014, at 3:00 AM, Peter Firmstone <j...@zeus.net.au> wrote:
>>>
>>>> Greg,
>>>>
>>>> We need to define the terms of reference for our discussion of
>>>> proposed changes. We need to avoid emotive arguments, like
>>>> “complete red herring”, “cascade of further failures” and “sweeping
>>>> changes”. I believe a much greater risk is not fixing issues, I
>>>> believe I can demonstrate that, given the opportunity. I also
>>>> encourage all who are interested to become involved.
>>>>
>>>> Which is why I’m asking you to vote on theory driven development:
>>>
>>> I will abstain from this vote.
>>>
>>> Cheers,
>>>
>>> Greg.
>>>
>>
>
