-
Notifications
You must be signed in to change notification settings - Fork 12
Bounded resource consumption refactoring #37
Conversation
| } | ||
|
|
||
| // Stops the LaunchDarkly client from sending any additional events. | ||
| // Shuts down the LaunchDarkly client. After calling this, the LaunchDarkly client |
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.
comment on exported method LDClient.Close should be of the form "Close ..."
| } | ||
|
|
||
| var ErrInitializationTimeout = errors.New("Timeout encountered waiting for LaunchDarkly client initialization") | ||
| var ErrClientNotInitialized = errors.New("Toggle called before LaunchDarkly client initialization completed") |
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.
exported var ErrClientNotInitialized should have comment or be unexported
|
This all seems reasonable. +1 for talking about this in person. |
| } | ||
|
|
||
| // Stops the LaunchDarkly client from sending any additional events. | ||
| // Shuts down the LaunchDarkly client. After calling this, the LaunchDarkly client |
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.
comment on exported method LDClient.Close should be of the form "Close ..."
|
lgtm |
…tion Bounded resource consumption refactoring
|
|
||
| store = config.FeatureStore | ||
|
|
||
| if !config.UseLdd && !config.Offline { |
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.
If LDD mode is set, then we will always timeout.
This is my proposed approach to bounding resource consumption in the go client. I also think this should be the reference model for all SDKs (save PHP and to a certain degree mobile) going forward. There are a number of ideas in here:
updateProcessorabstraction, so we're more cleanly separating the process of updating the feature store from reading the feature storeupdateProcessorimplementationLDClient, and we no longer ask it whether it's initialized. This is potentially a big performance win because we no longer make a remote redis call to check initialization on every toggle call.There's probably more here, so it's worth going over this in person as a group. But here is the first cut of it for early feedback.