Hi Henry, Thanks for checking it out. Your feedback is important on this issue. In fact, if you happen to know why ObserverHammerQuorumTest is failing with this latest patch, I'd love to hear.
I have a few reasons to prefer the approach in this patch rather than relying upon the ResponderThread. ResponderThread is legacy code, and we have been talking about deprecating that code. LE, and AFLE, although there is no final decision on making it happen yet. We need feedback from the community before deprecating, but this is at least what I have in mind.
The responder thread uses UDP currently, and we have written this connection manager class to take care of the TCP connections we use for leader election. To me it makes sense to use that facility instead of adding a new TCP responder thread. However, to use the connection manager, we currently need to do it through FLE.
Finally, I'd rather integrate all the logic for leader election instead of breaking up according to functionality. In fact, the changes to make observers work with FLE have been fairly simple so far, so I don't expect to have dramatic changes to make it happen, although I can't guarantee that changes will remain simple because I don't know yet why the observer hammer test is failing.
Does it make sense?