BatchSpanProcessor doesn't work across processes

[benjaminsky]

Describe your environment
Should be the same on all environments.

Steps to reproduce
Initialize the BatchSpanProcessor in a separate process from the instrumented code.

What is the expected behavior?
Spans should be exported when the BatchSpanProcessor worker thread runs in a different process

What is the actual behavior?
Spans are not exported when the BatchSpanProcessor worker thread runs in a different process than the instrumented code. Internally it uses a collections.deque which multiprocessing.Manager() doesn't support. Recommend changing this to multiprocessing.Queue.

[owais]

What are the downsides/implications of moving to multiprocessing.Queue?

[owais]

This might also help with uWSGI and gunicorn not working with the opentelemetry-instrument command.

It would be great to have this prototyped to figure out all implications of this change.

[srikanthccv]

Is it the underlying queue class reason for this behaviour? I thought it is because lock is acquired by deamon thread during the initialization and newly spawned processes will never be able to acquire it hence no spans are exported. I would like to see if moving to multiprocessing.Queue solves the problem.

[srikanthccv]

This should be fixed now.

[cruisehall]

This should be fixed now.

@srikanthccv could you link the PR that fixed this bug?

[srikanthccv]

here #2242