Summary

RPC requests require read-lock for consensus state and tx-processing requires write-lock while it apply txs to consensus state so both of two trigger lock contention.

Problem Definition

For example, "localhost:26657/status" rpc require consensusState.mtx.RLock() while it calls GetLastHeight() at https://github.com/line/tendermint/blob/404d27a892a54b8d94732b0e143f0f69b4dd8382/consensus/state.go#L220

And consensus logic can require this lock in here(https://github.com/line/tendermint/blob/404d27a892a54b8d94732b0e143f0f69b4dd8382/consensus/state.go#L674) and handleMsg(mi msgInfo) may call enterCommit() which may take long time to process several thousands txs in a block.

This situation raise two problems,

• rpc call can be hang while long txs processing
• tx processing can be delay for a short time by rpc calls

Proposal

When rpc requests read the consensus state, verify whether it is possible to read without a lock and modify it if possible to read without a lock.

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned