-
Notifications
You must be signed in to change notification settings - Fork 821
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
chore: adding metric observable to be able to support async update #964
Conversation
Codecov Report
@@ Coverage Diff @@
## master #964 +/- ##
==========================================
- Coverage 95.02% 94.95% -0.07%
==========================================
Files 209 210 +1
Lines 8541 8569 +28
Branches 766 770 +4
==========================================
+ Hits 8116 8137 +21
- Misses 425 432 +7
|
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 looks good thanks for this
|
||
next(value: number) { | ||
for (const subscriber of this._subscribers) { | ||
subscriber(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.
Can we use setImmediate(subscriber, value)
to avoid calling subscribers synchronously
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 think it would be a problem if we call them synchronously. The common pattern for such things is to make it synchronous. Also if user is calling "next" I would assume that this is the moment it should be updated, including the time as well, using setImmediate the time won't be accurate. I also think that this might cause some unexpected behaviour, if for any reason you would like to also call "collect" after you update values. I would be rather against 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.
Just to avoid blocking the event loop for too long if there are many subscribers to update, or if the subscribers take too long to process a value. A user may also subscribe
to updates, not just us, and the user is unlikely to know their callback is in a performance sensitive context
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 "hidden" async operation will prevent user from calling collect
immediately after updating the values, and time for updating the value will also be different then moment of calling next. Besides that "blocking loop" would last as long as callback in "standard way" 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.
@mayurkale22 @vmarchaud whats your thoughts on 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.
@vmarchaud setImmediate will delay update - it won't be updated asap as spec says
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 don't find any requirement on specific time requirement, could you give a link please ?
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.
@vmarchaud you wrote the spec state that the update path should be as fast as possible
so setImmediate won't update asap but it will update in next cycle
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 see, the whole spec state:
Metric updates made via a bound instrument, when used with an Aggregator defined by simple atomic operations, should follow a very short code path
I interpret short code path
from a performance requirement and not as a time requirement. So using setImmediate
would be a better solution for me
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'm strongly against it but if majority want's setImmediate with it's all consequences fine for me, @mayurkale22 you also vote for setImmediate ?
up ^^ |
From the javascript sig mtg today talking with @dyladan , sounds like having If |
…en-telemetry#964) * chore: adding metric observable to be able to support async update * chore: reviews * chore: reviews Co-authored-by: Daniel Dyla <[email protected]>
Which problem is this PR solving?
Short description of the changes