Setup instructions in conjunction with jaeger-client-python leads to pitfall

See https://github.com/uber/jaeger-client-python/issues/60. Doing the obvious setup, according to the readme of these two projects, leads to a deadlock which is quite tricky to sort out.

I’ve not yet found an elegant workaround, though I’m not an expert in Jaeger, or Django. In the linked issue, it’s suggested the Jaeger tracer not be initialized until after the WSGI server (gunicorn in my case) forks. That seems like a good idea, even if it didn’t deadlock.

The closest solution would seem to be putting the initialization of the Jaeger tracer in gunicorns post_fork() hook (or similar for other WSGI servers). Trouble is by that time I’d think OpenTracingMiddleware has already saved a reference to the tracer. So I’m looking at doing something ugly.

[mikebryant]

@ror6ax I’ve tried a different way of approaching this in #9

[tanner-bruce]

@dudymas I’m hoping to get back to it really soon, simply haven’t had a chance. There are a few things that need to be fixed in the PR, as well as a change or two and I need to rationalize some of the decisions. I also want to test a different approach to storing the root span that would make the middleware arguably cleaner.