-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[Event Hubs Client] Prefetch Size In Bytes Option #15141
[Event Hubs Client] Prefetch Size In Bytes Option #15141
Conversation
The focus of these changes is to introduce an option for the various event consumers allowing the prefetch cache to be filled based on a size-based heuristic rather than a count of events. This feature is considered a special case, helpful in scenarios where the size of events being read is not able to be known or predicted upfront and limiting resource use is valued over consistent and predictable performance.
ba32ecb
to
ea393b6
Compare
/azp run net - eventhub - tests |
Azure Pipelines could not run because the pipeline triggers exclude this branch/path. |
Manual run of the full suite taking place on the internal pipeline: #536700 |
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 (value.HasValue) | ||
{ | ||
Argument.AssertAtLeast(value.Value, 0, nameof(PrefetchSizeInBytes)); |
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 0
a valid value?
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.
Oddly enough, yes. That will have the net effect of "always prefetch exactly one event no matter the size",
Summary
The focus of these changes is to introduce an option for the various event consumers allowing the prefetch cache to be filled based on a size-based
heuristic rather than a count of events. This feature is considered a special case, helpful in scenarios where the size of events being read is not able to be known or predicted upfront and limiting resource use is valued over consistent and predictable performance.
Note: These API changes are part of a preview feature. The design and API surface were informally reviewed with the language architect but have not yet undergone formal review with the architecture board. I expect some changes, particularly around naming.
Last Upstream Rebase
Monday, September 14, 9:07am (EDT)
References and Related Issues