Please provide your thoughts on the following:
How do we develop code for River?
Do we only use experimental based development, or do we also allow
theoretical development also?
Do we only fix bugs that can be demonstrated with a test case, or do we
fix bugs identified by FindBugs and manual code auditing as well?
Should we allow theoretical development based on standards like the Java
Memory Model with visual auditing and static analysis with FindBugs, or
should we prohibit fixing bugs that don't include a test case
demonstrating the failure?
Regards,
Peter.
On 4/01/2014 6:58 PM, Patricia Shanahan wrote:
Just before Christmas, you were discussing whether to fix concurrency
problems based on theoretical analysis, or to only fix those problems
for which there is experimental evidence.
I believe the PMC will be at cross-purposes until you resolve that
issue, and strongly advise discussing and voting on it.
This is an example of a question whose answer would be obvious and
non-controversial if you had agreement, either way, on that general
issue. "When do you claim that this happens? And what currently
happens now that is unacceptable? What is the concrete, observable
problem that you’re trying to solve, that justifies introducing
failures that require further work?" is a valid, and important, set of
questions if you are only going to fix concurrency bugs for which
there is experimental evidence. It is irrelevant if you are going to
fix concurrency bugs based on theoretical analysis.
Patricia
On 1/3/2014 10:14 PM, Greg Trasuk wrote:
On Jan 4, 2014, at 12:52 AM, Peter Firmstone <j...@zeus.net.au> wrote:
On 4/01/2014 3:18 PM, Greg Trasuk wrote:
I’ll also point out Patricia’s recent statement that TaskManager
should be reasonably efficient for small task queues, but less
efficient for larger task queues. We don’t have solid evidence
that the task queues ever get large. Hence, the assertion that
“TaskManager doesn’t scale” is meaningless.
No, it's not about scalability, it's about the window of time when a
task is removed from the queue in TaskManager for execution but
fails and needs to be retried later. Task.runAfter doesn't contain
the task that "should have executed" so dependant tasks proceed
before their depenencies.
This code comment from ServiceDiscoveryManager might help:
/** This task class, when executed, first registers to receive
* ServiceEvents from the given ServiceRegistrar. If the
registration
* process succeeds (no RemoteExceptions), it then executes
the
* LookupTask to query the given ServiceRegistrar for a
"snapshot"
* of its current state with respect to services that match
the
* given template.
*
* Note that the order of execution of the two tasks is
important.
* That is, the LookupTask must be executed only after
registration
* for events has completed. This is because when an entity
registers
* with the event mechanism of a ServiceRegistrar, the
entity will
* only receive notification of events that occur "in the
future",
* after the registration is made. The entity will not
receive events
* about changes to the state of the ServiceRegistrar that
may have
* occurred before or during the registration process.
*
* Thus, if the order of these tasks were reversed and the
LookupTask
* were to be executed prior to the RegisterListenerTask,
then the
* possibility exists for the occurrence of a change in the
* ServiceRegistrar's state between the time the LookupTask
retrieves
* a snapshot of that state, and the time the event
registration
* process has completed, resulting in an incorrect view of
the
* current state of the ServiceRegistrar.
When do you claim that this happens? And what currently happens now
that is unacceptable? What is the concrete, observable problem that
you’re trying to solve, that justifies introducing failures that
require further work?
