mirror of
https://github.com/hanzomsg/nats-server.git
synced 2026-10-30 20:27:34 +00:00
NeilandGitHub
b194fde043
There is a possibility this might happen if `reConnectToRemoteLeafNode` from a connection drop and `connectToRemoteLeafNode` from solicitation are running in separate goroutines for the same remotes. Signed-off-by: Neil Twigg <[email protected]> --------- Signed-off-by: Neil Twigg <[email protected]>
32 lines
1.2 KiB
Plaintext
32 lines
1.2 KiB
Plaintext
Here is the list of some established lock ordering.
|
|
|
|
In this list, A -> B means that you can have A.Lock() then B.Lock(), not the opposite.
|
|
|
|
jetStream -> jsAccount -> Server -> client -> Account
|
|
|
|
jetStream -> jsAccount -> stream -> consumer
|
|
|
|
A lock to protect jetstream account's usage has been introduced: jsAccount.usageMu.
|
|
This lock is independent and can be invoked under any other lock: jsAccount -> jsa.usageMu, stream -> jsa.usageMu, etc...
|
|
|
|
A lock to protect the account's leafnodes list was also introduced to
|
|
allow that lock to be held and the acquire a client lock which is not
|
|
possible with the normal account lock.
|
|
|
|
accountLeafList -> client
|
|
|
|
AccountResolver interface has various implementations, but assume: AccountResolver -> Server
|
|
|
|
A reloadMu lock was added to prevent newly connecting clients racing with the configuration reload.
|
|
This must be taken out as soon as a reload is about to happen before any other locks:
|
|
|
|
reloadMu -> Server
|
|
reloadMu -> optsMu
|
|
|
|
The "jscmMu" lock in the Account is used to serialise calls to checkJetStreamMigrate and
|
|
clearObserverState so that they cannot interleave which would leave Raft nodes in
|
|
inconsistent observer states.
|
|
|
|
jscmMu -> Account -> jsAccount
|
|
jscmMu -> stream.clsMu
|
|
jscmMu -> RaftNode |