locksordering.txt

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