chore: adding metric observable to be able to support async update #964
Conversation
obecny
requested review from
bg451,
dyladan,
markwolff,
mayurkale22,
OlivierAlbertini,
rochdev and
vmarchaud
as code owners
obecny
added
the
size/L
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
|
|
|
||
| next(value: number) { | ||
| for (const subscriber of this._subscribers) { | ||
| subscriber(value); |
There was a problem hiding this comment.
Can we use setImmediate(subscriber, value) to avoid calling subscribers synchronously
There was a problem hiding this comment.
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.
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.
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.
@mayurkale22 @vmarchaud whats your thoughts on that ?
There was a problem hiding this comment.
@vmarchaud setImmediate will delay update - it won't be updated asap as spec says
There was a problem hiding this comment.
I don't find any requirement on specific time requirement, could you give a link please ?
There was a problem hiding this comment.
@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.
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.
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 <dyladan@users.noreply.github.com>
Which problem is this PR solving?
Short description of the changes