Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Forwarding the LanguageWorkerOptions from the host to the job host scope and ensuring we use the provided instances. #10369
base: dev
Are you sure you want to change the base?
Forwarding the LanguageWorkerOptions from the host to the job host scope and ensuring we use the provided instances. #10369
Changes from 5 commits
af614bb
bfbfe56
a1257e7
eec5806
706dc1f
624a870
1b8cff0
219cdf2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I am slightly concerned about how this will work in practice. There are subtleties to the way options are registered and calculated. I would feel better if we did the following:
Could even lift this to an extension method
IServiceCollection ForwardOptionsFrom<TOptions>(this IServiceCollection, IServiceProvider source);
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.
Can you expand on the concerns? I like the idea of wrapping that into an extension to make this cleaner and reusable (this is applied to other options). But for the functionality, in this case, we are explicitly trying to avoid another cache miss when using
IOptions<T>
, forLanguageWorkerOptions
specifically, given the cost of running its setup today and the state it tracks (those instances would be identical).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.
Also, one thing to note is that using the suggested pattern will defer execution of the setup to the time services in the child container request the options, if nothing at the host scope consumes one of those option types.
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.
That was intentional. I wanted to ensure
IOptions
in both parent and child container would be the same values. Otherwise, the two containers could potentially have different values if config changes between the two. Unlikely, but that would be one confusing bug if it ever happens.Would this cache miss not already exist in the parent container?
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.
With the pattern currently used in the code, the values would be the same, also refreshed when using
IOptionsMonitor
, one of the differences is that when usingIOptions<T>
, you'd end up with the same instance that is returned byIOptionsMonitor<T>
(at the initial construction here), but that's intentional.Right now, there are two cache misses in the JobHost/ScriptHost scope with every single initialization:
IOptionsMonitor<LanguageWorkerOptions>
IOptions<LanguageWorkerOptions>
If no WebHost services are using
IOptions<LanguageWorkerOptions>
(or if that ever changes in the future as a result of changes to WebHost scoped services), we'd end up with a cache miss when initializing the JobHost, which would have an impact on cold start in some cases (specialization flows shouldn't be as impacted as the expectation is that placeholders would have forced this to happen).The
IOptions<LanguageWorkerOptions>
is the second hit we're trying to avoid.For the WebHost, in specialization cases, even if the host has services consuming
IOptions<LanguageWorkerOptions>
, those wouldn't impact customer cold start as they would happen in placeholders.Ultimately, much of what we're dealing with here is the fact the this current setup implementation is doing way too much and that logic should be refactored into a separate, singleton, service that is reused, avoiding the duplicate execution of that expensive logic that is not expected to run more than once anyway.
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 WebHost won't ever be realizing
IOptions<LanguageWorkerOptions>
when we have a customer payload? If that is the case, then I am fine with the approach as is.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.
Is
worker.latestConfiguration.json
a new thing?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.
This is looking like an accidental change to me. I don't expect a different file name.
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.
Can you explain the intention behind this? The comment says to use
IOptionsMonitor<LanguageWorkerOptions>
, but won't this class still run (and fail) for that type?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 message is a bit confusing, but with the forwarding, no setups should run for
IOptionsMonitor<LanguageWorkerOptions>
within the JobHost scope. The same applies toIOptions<LanguageWorkerOptions
, though, so either option would take the host injected instances and not run any setup logic within that scope.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.
Ah, can we clarify that?
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.
What's the scenario here, and why didn't we have this behavior before?
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.
Will need to review this to comment. That's part of a set of changes pushed by @kshyju .
Changes to the signal used to reload
LanguageWorkerOptions
were required. I'm concerned that the logic here is assuming this will always change as a result of specialization, which may change in the future.At the very least, the message needs to be a bit more descriptive.