When we have cluster

{A,B,C} and invoke an RPC (via RpcDispatcher), then the target membership will be {A,B,C}

and we block until we have responses from A, B and C (or a timeout).

If the timeout is 0 (= wait forever), and we created a GroupRequest in MessageDispatcher.castMessage() (called from RpcDispatcher.callRemoteMethods()), then the request is sent down the stack.

If just at this moment - after the request was sent, but before we received all responses - a new member D joined and we get

{A,B,C,D}

, then the expected responses hashmap in GroupRequest is modified and D added. This means, we will wait for D's response although it never actually received the request, resulting in a block !

SOLUTION: view changes can only remove but not add elements in the GroupRequest's hashmap, e.g. if B left while waiting for responses, then B's entry would be removed (or marked as 'received' or 'suspected', TBD).

Another thing to look into is whether we want to ship the target destination list with a request and have members drop the request if they are not part of that list. One could argue that this should only be done at the caller's side