adding multithreading tests for batch processor#947
adding multithreading tests for batch processor#947aravinsiva wants to merge 2 commits intoopen-telemetry:masterfrom
Conversation
| span_names1 = ["yyy", "baz", "fox"] | ||
|
|
||
| for name in span_names0: | ||
| _create_start_and_end_span(name, span_processor_to_flush) |
There was a problem hiding this comment.
Not super familiar with this code, but what happens if spans are "created" by one thread while the other thread is shutting down? Is that something we should test as well?
There was a problem hiding this comment.
this is a great point. The only reason I didn't look into that in particular is because the two methods outlined in the issue were force_flush() and shutdown()
aabmass
left a comment
There was a problem hiding this comment.
What is the race condition we are testing here?
|
@aravinsiva |
My mistake have been busy tackling another project. And it is currently testing that these can be called concurrently without causing a change in the end resulting spans. Feel free to let me know if this is not the correct approach to test what we want to be tested. |
| span_processor_to_shutdown.shutdown() | ||
| self.assertTrue(span_processor_to_flush.force_flush()) |
There was a problem hiding this comment.
@lzchen is this what you meant by:
I believe they are referring to the behaviour for
shutdownandforce_flushwhen they are called at the same time in different threads (e.g. multiple BatchSpanProcessors)
It looks like shutdown() would block until its done exporting
So they wouldn't be called at the same time unless you actually did it in separate threads. Even if you did it in separate threads, the test might be flaky since you can't guarantee the order of execution.
There was a problem hiding this comment.
^ is this not tested in the way the test has been written currently @lzchen ? As I am calling force_flush and shutdown() manually. unless there is something I am not understanding.
There was a problem hiding this comment.
They are not called at the same time though, since your call to shutdown() doesn't return until it is done exporting
|
Closing this PR, the work needed to ensure that the tracerprovider api is safe to use concurrently is still needed. |
…#947) Co-authored-by: Daniel Dyla <dyladan@users.noreply.github.com>
Add's concurrency tests to ensure that force_flush() and shutdown() could be called concurrently without causing racing coniditions.
Addresses:
#392