Incompatible with django-channels

[scottkidder]

This was mentioned in #65 but it is very old.
Even putting silk middleware as the very first item in MIDDLEWARE doesn't prevent the error.

How can we work around this to at least use Silk to profile everything but channels?

[garfonzo]

I get the exact same results as described in #65. Although for me, I don't have django-channels, but I do have a multi-tenant DB with django-tenants http://django-tenants.readthedocs.io/en/latest/index.html

First request works, all the rest fail.

[Atorich]

+1. Fails when using django-channels (exception about not properly installed middleware)

[regzon]

+1

[fish-face]

So as far as I can tell this is just because ASGI applications don't use the same middleware, but do (possibly) make SQL queries. Silk probably needs to provide a channels-compatible middleware.

[auvipy]

That's natural. @carltongibson what do you think about the @fish-face comment?

[carltongibson]

#65 (comment):

It seems running runserver --nothreading fixes the problem, but that can't be the solution.

I'm guessing this is a threading issue.

Channel's AsgiHandler does load and use the normal Django middleware chain. (This is why Django behaves as expected, in general, when run via Channels.)

So what's going on? Well, without looking more, I don't yet know but, ultimately we're dispatching the view inside a sync_to_async() wrapper, which executes the code in a thread. Given that disabling threading "fixed" the problem with runserver I think it likely we're seeing the result of some contention there. (I'd need to look to say more, but I don't have capacity for that at the moment.)

So, what to do?

I think the simplest bet right now would be to run a WSGI server to handle traditional HTTP and then your ASGI server for websockets etc. (i.e. you don't need to run sync things through ASGI.) Use Nginx (or whatever) to route requests to different backends depending on path or protocol or ...

I hope that's of some help.