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.
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?
If somebody else on this list would say, i can wholeheartedly support the changes and it only became more solid. It can stay the way it is.
To be honest, i don't have the time to do a torough code inspection, so i'm a bit on the conservative side right now.
My opinion. Gr. Sim -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
