Refactor fastNodeCache
and nodeCache
to be separate modules with synchrony
#24
Closed
9 tasks
Labels
enhancement
New feature or request
good first issue
Good for newcomers
help wanted
Extra attention is needed
tech-debt
Background
fastNodeCache
andnodeCache
innodeDb
are resources accessible by several go routines.There are 2 problems with the current design:
When we update one, we need to update all other 3. The current implementation makes the code less readable since we need to update all 3 and many places in nodedb.
Background
fastNodeCache
andnodeCache
innodeDb
are resources accessible by several go routines that persist nodes in an LRU fashion.Problem
There are 2 problems with the current design:
When we update one, we need to update all other 3. The current implementation makes the code less readable since we need to update all 3 in many places in nodedb.
nodedb
.Sometimes we might be reading resource A while using the common lock. At the same time, another goroutine wants to read resource B but has to wait on that exact same lock
Solution
Instead, we can have an interface:
This way, we would be able to decouple cache from nodedb, improve the readability of the code and make it less brittle.
In addition, by decoupling
NodeCache
and letting each has its own mutex, we will solve the performance issue of having to wait on the common lock while accessing different resourcesLastly, by having a
NodeCache
interface, we can easily mock it withgomock
Before You Start
This issue is blocked by #24 , #24 should be done before this issue
Acceptance Criteria
NodeCache
interfaceTreeNodeCache
struct (see RefactorfastNodeCache
andnodeCache
to be separate modules with synchrony #24 for whatTreeNode
is)TreeNodeCache
nodedb
with the mockFastNodeCache
structTreeNodeCache
nodedb
with the mockThe text was updated successfully, but these errors were encountered: