Thanks Gregg,
I appreciate your support, I've been playing around with your suggestion, it's
good advise, will share changes shortly.
The intent of present efforts is to increase the reliability and predictibility
of the codebase while maintaining backward compatibility.
However after the code
From the very early days of Jini, I have not had good luck with
ServiceDiscoveryManager. I actually have perhaps 3 different version of this
behavior coded into various applications in different ways, because SDM just
did not seem to provide sane behavior for me, ever. I am not sure that I hav
I recently updated RetryTask to implement RunnableFuture (it had very similar
methods), it also no longer implements Task.runAfter which has been pushed down
to subclasses that use it (aka those in ServiceDiscoveryManager) it wouldn't
take much effort to add functionality to RetryTask to allow l
Gregg,
Are you able to help out with ServiceDiscoveryManager?
Fixing SDM would make a huge stability improvement.
Guava has an interface called ListenableFuture, which sounds like a possible
candidate, listeners are registered and notified in the event of failure or
success.
The Guava site cl
I think the better choice is to not try and handle failure with retry at all.
Instead, we should use API which allows the dependent task to know whether it’s
dependent has completed or failed. It can then report failure if its dependent
failed, or submit its own work to be executed in the que
For a moment, lets consider how we might fix TaskManager, while retaining the
existing Task.runAfter method and how the fix would impact TaskManager's users.
TaskManager, like most thread pools has a queue.
Before a task is removed from the queue for execution, it is asked if it should
"runAfte
The problem is with TaskManager's public api method Task.runAfter. This is
well documented in River-344.
The fix requires changing every class that uses it
As a thread pool TaskManager is correct provided that no ordering dependencies
exist between tasks.
TaskManager doesn't compare to Doug L
I’d like you to make a reasonable case for why TaskManager needs to be
replaced, requiring changes to many other classes that depend on TaskManager,
rather than stating what the problem is with TaskManager and seeking to fix it,
which would only affect TaskManager and not require modifying and
