-
Notifications
You must be signed in to change notification settings - Fork 711
addressing concurrency issue in Span API #1259
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
addressing concurrency issue in Span API #1259
Conversation
Before this change, the following would cause unintended behaviour in the Span API's add_event, update_name and set_status methods: - thread A calls set_status, locks to check if a span has ended, and releases the lock - thread B obtains the lock and ends a span - thread A continues its call of set_status This change ensures that the update operations are done with the lock being held. It's done in a decorator, but that is completely optional.
@@ -575,15 +586,8 @@ def set_attribute(self, key: str, value: types.AttributeValue) -> None: | |||
with self._lock: | |||
self.attributes[key] = 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.
What about set_attribute
?
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 yeah good point, I saw the lock here and thought it was safe from this condition, but it is not. will fix
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.
Updated
Description
Before this change, the following would cause unintended behaviour in the Span API's add_event, update_name and set_status methods:
This change ensures that the update operations are done with the lock being held. It's done in a decorator, but that is completely optional.
Fixes #1157
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
I updated the code in
set_status
to raise an exception when the status was updated on an already ended span and was able to reproduce the issue, it was too unreliable to write a unit test for it. The only way I managed to reproduce with about 1% of the time was to introduce a delay inset_status
Checklist: