RESULT: [VOTE] Theory based development
Results: +1 Peter Firmstone (PMC) +1 Bishnu Prasad Gautam +1 Luis Matta Abstain: Greg Trasuk I would have liked to see more participation from PMC members, since this is a vote on a procedural matter and as there have been no objections after 72 hours, under Apache voting rules it passes.
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
On Jan 22, 2014, at 657AM, Peter j...@zeus.net.au wrote: Startable only had one purpose: To provide the implementor a thread of execution after construction completes. It's provided by the the infrastructure to the service implementation, what the implementor does with it is their business. By itself it's harmless, but the point being here is that the Startable interface semantics cannot enforce the problem you are trying to solve. One alternative was, for our service implementations to be moved to abstract classes and threads started and exporting performed in stateless concrete classes, the other was to removal all final field modifiers, Startable was simple and seemed more elegant. That's about it in a nutshell, sorry if you got the impression it had another purpose. The problem with the tests; they've had bug fixes too, so people have trouble trusting them. The section of code you've found in Outrigger is ugly but correct, ideally sync would be the responsibility of resource but in this case it's external. Synchronizing on local variables is usually a bad idea. If the object that resource points to will *always* be the same, then the synchronized(resource) block does in fact use that quasi-global object's monitor. IMO it would be a better practice to use a synchronized wrapper here. Dennis
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
I was more thinking along the lines of encouraging best practise. Right now, if you read River's service implementations, every single one uses final fields and publishes partially constructed service reference to other threads, the hotspot compiller is free to reorder so these, so threads see partially constructed objects and default values for final fields. The reference shared during export is never updated, so threads carrying method invocations from remote clients never see a safely published reference and there is no way to obtain one at present. If people want it enforced, I could create a private class, that extends SecurityManager, walks the call stack, checks if export is being performed during construction, then use reflection to check for final fields and throw an exception if it does, but that doesn't ensure the service is thread safe. Presently we expect service implementations to be thread safe (remote method invocation is performed via a thread pool), but River doesn't provide an easy way for implementors to use final fields. Services can also use static methods and writeReplace, provided they're not using the starter kit. Peter. - Original message - On Jan 22, 2014, at 657AM, Peter j...@zeus.net.au wrote: Startable only had one purpose: To provide the implementor a thread of execution after construction completes. It's provided by the the infrastructure to the service implementation, what the implementor does with it is their business. By itself it's harmless, but the point being here is that the Startable interface semantics cannot enforce the problem you are trying to solve. One alternative was, for our service implementations to be moved to abstract classes and threads started and exporting performed in stateless concrete classes, the other was to removal all final field modifiers, Startable was simple and seemed more elegant. That's about it in a nutshell, sorry if you got the impression it had another purpose. The problem with the tests; they've had bug fixes too, so people have trouble trusting them. The section of code you've found in Outrigger is ugly but correct, ideally sync would be the responsibility of resource but in this case it's external. Synchronizing on local variables is usually a bad idea. If the object that resource points to will *always* be the same, then the synchronized(resource) block does in fact use that quasi-global object's monitor. IMO it would be a better practice to use a synchronized wrapper here. Dennis
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
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. signature.asc Description: This is a digitally signed message part
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
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.
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
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.
[VOTE] Theory based development
One of my first tasks on joining the Apache River project was to implement support for Java 5 language features in ClassDep . I don't recall who requested Java 5 language feature support, however this seemed like a good place to start, based on an initial contribution from Tim Blackmann. The ClassDep api remained the same, however the underlying implementation was completely rewritten. This work has been included in all releases of Apache River since I joined and I'm yet to hear one complaint, without it, the transition to Java 5 may have been quite different. Moving on to our current circumstance, most of River's code pre dates the Java Memory Model released with Java 5, it would be unreasonable to expect code pre dating a standard to be compliant with it. My attempts to fix random intermittent test failures, unrelated to code changes, but affected by timing, has lead to a cascading series of failures, every time I fixed a problem a new problem would appear. FindBugs no longer reports many multi-threaded issues in release code (FindBugs isn't instrumented to analyse classes that use ReadersWriter), although quite a few remain in the test suite. I believe the majority of multi threaded issues are fixed, with some remaining hold outs based on TaskManager.Task.runAfter() and other remaining in the test suite. The major problem that faces my development now however is not multi threaded bugs, instead it is the River development community remaining undecided on supporting or not supporting Theory based development. My reasoning is this: 1. To ameliorate issues reviewing change raised by other developers, I plan to document my changes on Jira (this will be a huge effort that will take months). 2. Many of these issues are based on theory and analysis, many examples will be fields accessed from multiple threads without synchronisation, but there will be no test cases exposing bugs (most concurrency bugs are not repeatable). 3. My recent attempt to create an interface Startable, met with much controversy. I'm sure that if I had supplied a test case demonstrating a failure there would be no argument, however because my analysis was based on theory, the alternative solution posed was things were acceptable the way they were and that object construction would be complete before other threads could see the reference (without any evidence to prove otherwise either). 4. There is a significant risk, with theoretical based issues raised on Jira, that the status quo will prevail and my efforts wasted. The right thing to do is at least tell me, as your fellow developer, whether the community supports theory based development or not, to save me wasting time fixing any more bugs or documenting them, (if that is the case) and to allow me to focus on something the community does support. If the community does support theory based development, then I suggest we pose the issue of publishing an object with final fields where other threads can see it, prior to its constructor completing to the concurrency interest list and see what the experts thoughts are, then I'd propose we also use this approach with other issues, by consulting experts in each field relating to a bug? Do you support theory based development? +1 Peter Firmstone.
