On 27/11/2012 10:12 PM, Simon IJskes - QCG wrote:
On 27-11-12 12:58, Peter Firmstone wrote:
When faced with difficult concurrency problems, I've had success in the
past by refactoring. Trouble with concurrency bugs; you can't always
tell where they are, consider it a brute force debugging attempt,
sometimes it pays off.
Correct. You are right.
If you prefer ReggieImpl how it was previously we can change it back
after all tests are passing.
I see valuable things, like the generics, which i would like to keep.
The guarded collections only if needed, and volatile less of a
problem. The lock/TODO stuff needs to go IMHO. Network stuff needs
inspection. Reordering threat startup, only if confirmed by other team
member.
One issue I can see; threads are started outside of the
Subject.doAsPrivileged context.
The only thing i'm worried about, with these 'big' changes are the
small changes in behaviour that cause problems in existing
installations. What do you do in these cases, leave the old version,
and never improve? Or put in the new version with exposing subtle bugs?
The beauty of the lookup service is we can revert the changes and design
a drop in an alternate implementation with fresh modern concurrent
code. Then the users can choose which version they use.
This was more a brief experiment in solving some concurrency bugs, we
can revert most changes to Reggie once the tests are confirmed passing.
Regards,
Peter.
