82c7efccf8
processBatchedChanges queued each pending change for a node as a separate work item. Since multiple workers pull from the same channel, two changes for the same node could be processed concurrently by different workers. This caused two problems: 1. MapResponses delivered out of order — a later change could finish generating before an earlier one, so the client sees stale state. 2. updateSentPeers and computePeerDiff race against each other — updateSentPeers does Clear() + Store() which is not atomic relative to a concurrent Range() in computePeerDiff. Bundle all pending changes for a node into a single work item so one worker processes them sequentially. Add a per-node workMu that serializes processing across consecutive batch ticks, preventing a second worker from starting tick N+1 while tick N is still in progress. Fixes #3140 |
||
|---|---|---|
| .. | ||
| batcher.go | ||
| batcher_bench_test.go | ||
| batcher_concurrency_test.go | ||
| batcher_scale_bench_test.go | ||
| batcher_test.go | ||
| batcher_unit_test.go | ||
| builder.go | ||
| builder_test.go | ||
| mapper.go | ||
| mapper_test.go | ||
| node_conn.go | ||
| tail_test.go | ||