-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
graph: extract cache from CRUD [6] #9555
graph: extract cache from CRUD [6] #9555
Conversation
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
7505858
to
bb3af46
Compare
5eb96dc
to
3ce4799
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🍫
@@ -119,6 +88,13 @@ func (c *ChannelGraph) Start() error { | |||
log.Debugf("ChannelGraph starting") | |||
defer log.Debug("ChannelGraph started") | |||
|
|||
if c.graphCache != nil { | |||
if err := c.populateCache(); err != nil { | |||
return fmt.Errorf("could not populate the graph "+ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: the started flag remains dirty, but i think that's okay since we likely won't try to start the same graph instance again.
if !c.started.CompareAndSwap(false, true) { | ||
return nil | ||
} | ||
log.Debugf("ChannelGraph starting") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
log.Debugf("ChannelGraph starting") | |
log.Debug("ChannelGraph starting") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a pattern for choosing the format when using a simple string, or does it not matter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as it conveys useful info to the user
started atomic.Bool | ||
stopped atomic.Bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need two booleans (started
and stopped
) to track the state? Wouldn't a single atomic boolean be enough? Using just one (active
, for example) would simplify the logic and prevent inconsistent states like started = true
and stopped = true
at the same time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these should be read as "has this service ever been started" and "has this service ever been stopped" . So both being true is legit.
We use this pattern throughout the code-base. Services are not restartable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need two booleans (started and stopped) to track the state?
Very good question! In addition to Elle's comment I do think using one var makes things easier as it prevents inconsistent states, we may consider changing it one day but it's not our priority atm, plus it's working fine so far.
We do this in preparation for moving channel cache population logic out of the constructor and into the Start method. We also will later on (when topology subscription is moved to the ChannelGraph), have a goroutine that will need to be kicked off and stopped.
…ction In this commit, we move the graph cache population logic out of the ChannelGraph constructor and into its Start method instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧹
@@ -184,13 +184,12 @@ const ( | |||
type KVStore struct { | |||
db kvdb.Backend | |||
|
|||
// cacheMu guards all caches (rejectCache, chanCache, graphCache). If | |||
// cacheMu guards all caches (rejectCache and chanCache). If |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
} | ||
|
||
// The graph cache can be turned off (e.g. for mobile users) for a | ||
// speed/memory usage tradeoff. | ||
graphCache := NewGraphCache(opts.preAllocCacheNumNodes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🌟
started atomic.Bool | ||
stopped atomic.Bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need two booleans (started and stopped) to track the state?
Very good question! In addition to Elle's comment I do think using one var makes things easier as it prevents inconsistent states, we may consider changing it one day but it's not our priority atm, plus it's working fine so far.
btw the itest |
Investigating 👍 |
1293f2e
into
lightningnetwork:elle-graphCacheBase
** Final PR in the cache-RIP series **
This builds towards this final result by building this side branch incrementally.
In this PR, the extraction of the
graphCache
from the CRUD layer (KVStore
) into theChannelGraph
layer is completed.The opportunity is also taken to move the graphCache population logic out of the constructor of the ChannelGraph and into
a new
Start
method instead.