Some great points Bruce!!
I believe this whole thread Monitoring feature needs to have the scope
expanded... I mean.. We would either require compensatory events to
rollback ANYTHING that the thread had been doing until the point it was
killed.
When it was proposed, I understood it as a mech
This looks like a dangerous change that is putting a fixed time limit on
execution of arbitrary jobs with no real check to see if threads are
stuck or not. If a thread is doing some heavy lifting it could be
killed with Thread.stop() in the middle of its work. Think initial image
transfer, for
This seems like a really bad idea. It's using the long-deprecated
Thread.stop() to kill executor threads that take too long to execute.
It has no idea what state the thread is in when it kills it. It could
be doing disk I/O or writing to shared memory.
On 6/4/18 9:50 AM, Kirk Lund wrote:
Can a couple more folks please review PR #1868?
My review feedback pertained only to using dependency injection instead of
a singleton or static getter and Yossi has updated the code as I requested.
My review doesn't really address the usefulness of the feature or the
impact on features that were
