Daphne 3.0 problem with request-response when working with Channels

Hi,

I’m facing a strange issue with Daphne 3 + Channels 3.0.2 and handling multiple request. I setup a really simple project so we have a base for discussion 😃 So, I’m running the project on OS Ubuntu 18.04 with python 3.7. My requirements are:

Django==3.1.3
daphne==3.0.0
channels==3.0.2
django-environ==0.4.5

My setup

1. I registered channels in installed apps and pointed to this routing:

application = ProtocolTypeRouter({
    'websocket': URLRouter([])
})

1. I added 2 simple views:

def view_1(request):  # Url is `/1/`
    make_it_slow()  # Sleeps for 3 seconds
    return HttpResponse('view_1 response')


def view_2(request):  # Url is `/2/`
    make_it_slow()  # Sleeps for 3 seconds
    return HttpResponse('view_2 response')

1. I ran the application:

daphne daphne_3_issue_demo.asgi:application

The issue

So I opened 2 shells and ran these in parralel: curl http://localhost:8000/1/ and curl http://localhost:8000/2/

So what I noticed is that the first finished response arrives to the last requesting client and the other request just hangs until it times out.

Here’s what I mean:

P.S.: I think this issue is extending the existing one but it’s not the exactly the same.

Best regards, Ivo

[Ivo-Donchev]

@carltongibson I found the problem. It’s not Daphne

The problem was: Our production project was (and still is) using django 2.2 with channels 2.x and daphne 2.x. Channels 2.x used to allow not specifying the http application inside the ProtocolTypeRouter, where channels 3.x seems change the behaviour and if you directly update the dependencies and skip reading the new docs (like I did) it started producing this weird bug with the parallel requests.

So to solve this I just put both http and websocket protocols at one place inside ProtocolTypeRouter. I guess it’ll be a good idea if it had some warning… but that’s definetely not a Daphne problem . Sorry for the fake alarm and thanks for the quick response again 🙂

P.S: That could actually be a fix for the other issue mentioned above - https://github.com/django/daphne/issues/344 🤔

[Ivo-Donchev]

@carltongibson I actually jumped in channels’ the code a little bit to checkout for a good place to put such warning and it turned out there’s one - https://github.com/django/channels/blob/master/channels/routing.py#L63 👍 . However it wasn’t shown in the server logs - neither runserver nor daphne. Maybe it needs some additional logging configuration than the default one.

Thinking out loud: I think it’s Django job to make sure the application instance (no matter it’s channels or something else) is done just once probably even in the View and Consumer implementations since since they’re always the very last end points for all routes. That could handle most of the cases: someone using Django as pure http server or pure websocket server (which will raise a warning at the moment) + someone trying to handle any of http/websocket protocols at 2 places. Also - it’ll handle both runserver and daphne or other production application server. But I’m not into the very details of the server handling implementation, just throwing some “make sense to me” ideas here 🙂