During peer removal, try to remap any stream or consumer assets. #2493
Conversation
Also if we do not have room trap add peer and process there. Fixed a bug that would treat ephemerals same as durables during remapping after peer removal. Signed-off-by: Derek Collison <[email protected]>
| csa := sa.copyGroup() | ||
| csa.Group.Peers = append(csa.Group.Peers, peer) | ||
| // Send our proposal for this csa. Also use same group definition for all the consumers as well. | ||
| cc.meta.Propose(encodeAddStreamAssignment(csa)) |
There was a problem hiding this comment.
I dont know the flows of this code much - but this Propose can block, and with enough streams this can take a very long time especially if the propose channel fills, is that ok? We could even lose leadership during this?
Mainly just curious how the code work, sure its fine
There was a problem hiding this comment.
Yes all of those things can happen. The way we mitigate is to only stay in place for a client, and run outside of main route loops and GWs.
This code can block, but is in its own Go routine already processing the raft layer.
There was a problem hiding this comment.
Just want to point out that we have the js lock at the top of the function, so by blocking I figure you mean waiting for some other nodes to do something. If it is waiting on something in the same process, then we may have an issue since we are holding the js lock.
There was a problem hiding this comment.
Only thing we wait on would be underlying raft layer to drain propc chan.
Also if we do not have room trap add peer and process there.
Also fixed a bug that would treat ephemerals the same as durables during remapping after peer removal.
Signed-off-by: Derek Collison [email protected]
/cc @nats-io/core