django-eventstream icon indicating copy to clipboard operation
django-eventstream copied to clipboard

send_event function does not work on linux server

Open Moshikol opened this issue 5 years ago • 21 comments

Hi guys,
I'm using Django-eventstream over Django channels to send an event to my client app,
on my local machine, the events are sent correctly to the client.
but when I upload the app to my Linux server the webhook just getting open and 'keep-alive' but the events won't get to the client at all. I use daphne to deploy my Asgi app and use Nginx as my getaway.
when I use python manage.py runserver (on the Linux server) the client is getting the messages.
I don't see the events trying to be sent in the daphne logs as well.
does anyone have a clue why this is happening? Thanks!

Moshikol avatar Dec 05 '19 09:12 Moshikol

Make sure you're not using multiple daphne processes. Multiple threads is fine.

jkarneges avatar Dec 07 '19 19:12 jkarneges

Make sure you're not using multiple daphne processes. Multiple threads is fine.

I have only one process of daphne running along side gunicorn which run my WSGI app. Here is the command i use for running my daphne server daphne --verbosity 3 -p 8001 my_project.asgi:application

here is my Daphne log:

06/12/2019 14:52:34] INFO [daphne.cli:287] Starting server at tcp:port=8001:interface=127.0.0.1
2019-12-06 14:52:34,376 INFO     Starting server at tcp:port=8001:interface=127.0.0.1
[06/12/2019 14:52:34] INFO [daphne.server:311] HTTP/2 support enabled
2019-12-06 14:52:34,377 INFO     HTTP/2 support enabled
[06/12/2019 14:52:34] INFO [daphne.server:311] Configuring endpoint tcp:port=8001:interface=127.0.0.1
2019-12-06 14:52:34,377 INFO     Configuring endpoint tcp:port=8001:interface=127.0.0.1
[06/12/2019 14:52:34] INFO [daphne.server:131] HTTPFactory starting on 8001
2019-12-06 14:52:34,378 INFO     HTTPFactory starting on 8001
[06/12/2019 14:52:34] INFO [daphne.server:131] Starting factory <daphne.http_protocol.HTTPFactory object at 0x7fb1fd600cf8>
2019-12-06 14:52:34,378 INFO     Starting factory <daphne.http_protocol.HTTPFactory object at 0x7fb1fd600cf8>
[06/12/2019 14:52:34] INFO [daphne.server:654] Listening on TCP address 127.0.0.1:8001
2019-12-06 14:52:34,379 INFO     Listening on TCP address 127.0.0.1:8001
[06/12/2019 14:52:38] DEBUG [daphne.http_protocol:160] HTTP b'GET' request for ['127.0.0.1', 49034]
2019-12-06 14:52:38,215 DEBUG    HTTP b'GET' request for ['127.0.0.1', 49034]
[06/12/2019 14:52:38] DEBUG [daphne.http_protocol:246

Moshikol avatar Dec 07 '19 20:12 Moshikol

I just did some testing of the examples in this repo, and the chat example works fine with runserver or daphne, but I noticed the time example only works with runserver. For some reason time's background thread doesn't get triggered when running with daphne.

Are you doing something like the time example, where the events come from something in the background rather than triggered by a client request?

jkarneges avatar Dec 07 '19 20:12 jkarneges

I just did some testing of the examples in this repo, and the chat example works fine with runserver or daphne, but I noticed the time example only works with runserver. For some reason time's background thread doesn't get triggered when running with daphne.

Are you doing something like the time example, where the events come from something in the background rather than triggered by a client request?

I call the send_event in django view ( with some logic) which triggered on an API call. Do you have any idea what the difference between the two repos?

Moshikol avatar Dec 07 '19 20:12 Moshikol

Hard to say. You could try using the same dependency versions as the chat example (I just updated them to the latest), or deploy the chat example in an environment similar to your production environment to compare.

jkarneges avatar Dec 07 '19 20:12 jkarneges

Maybe its related to the channel routing difference the chat app uses the formatted channel type and the time app uses channel. So my next move is to try to find the difference between my dependencies and the chat app dependencies hope it would help

Moshikol avatar Dec 07 '19 20:12 Moshikol

If you have any other suggestions im open to hear Thanks

Moshikol avatar Dec 07 '19 22:12 Moshikol

still no luck ..

Moshikol avatar Dec 09 '19 16:12 Moshikol

What if you deploy the chat example as-is? Does it work for you?

jkarneges avatar Dec 11 '19 16:12 jkarneges

@jkarneges can you guide me a bit on how to deploy it ? i tried doing it with daphne on my local machine and it did not work.. maybe im missing somthing

Moshikol avatar Dec 11 '19 16:12 Moshikol

What problem did you get? Note that the static files won't be served if daphne is run directly. I tried first with runserver in order to load the page along with the static assets. Then specify a nickname to join the default room. Then once the room loaded, I ctrl-c the runserver and launch daphne:

daphne server.asgi:application

Then wait a moment and the room reconnects. If I send a message it works.

jkarneges avatar Dec 12 '19 02:12 jkarneges

I know it is been a while, but i'm having the same problem here, my daphne is ok, the connection is ok, but the send_event never reach the client, the stream gets only keep-alive. It happens only in production, any help will be appreciated!

diogonfs avatar Jun 20 '20 06:06 diogonfs

I have one daphne instance. My deploy is daphne + uwsgi with nginx, where certain urls are directed to daphne. Does the send_event code has to be executed from a view called by an asgi url?

diogonfs avatar Jun 20 '20 07:06 diogonfs

Hi @diogonfs , it should be okay to call send_event from anywhere within the process, for example from a spawned thread rather than from a view.

jkarneges avatar Jun 20 '20 15:06 jkarneges

Thanks for the help! My nginx redirects some url calls to daphne while the others are served by uwsgi, i think the problem is that my send_event is callled when one of my uwsgi urls is called (is not exactly in the view, but in a code that gets called when a view is executed) and so from another process. In this case, the send_event should have been called from the daphne served url to be executed from the same process, right?

diogonfs avatar Jun 20 '20 23:06 diogonfs

Indeed, if you call send_event from the uwsgi process then nothing will happen.

jkarneges avatar Jun 21 '20 00:06 jkarneges

@Moshikol for reference, I also had the same issue in production while all the configurations were OK (or at least I think), but no luck. I solved using hypercorn instead of daphne and everything worked at the first time, I just had to disable gzip compression for the /events url. Using daphne I had another issue (for some reason the request object was an empty string in some view), also solved using the other server.

paolodina avatar Jul 03 '20 00:07 paolodina

@paolodina I'm having some similar issues though hypercorn alone didn't solve it for me - how did you disable gzip compression just just the /events url?

mando238 avatar Aug 04 '20 00:08 mando238

@mando238 with Caddy2 the conf is

example.com {
    @notGzip {
        not path /events*
    }
    encode @notGzip gzip
    reverse_proxy 127.0.0.1:8000
    file_server
}

paolodina avatar Aug 04 '20 06:08 paolodina

Indeed, if you call send_event from the uwsgi process then nothing will happen.

I might be dumber than the average Dev, but it took me a little while to figure out this was my issue on my production server. I had to redirect all the views that had send_event() in them to my Daphne server with Nginx.

What really threw me for a loop is it mysteriously worked when I first set it up and then it just stopped sending the messages the next day.

A note below, "To send data to clients, call send_event:", that says, "send_event() must be called from ASGI in production. Calling send_event() from uwsgi will cause messages to go no where without error.", would probably help :)

I know the ASGI server is implied since I was serving it through Channels but still it's a nice bit of text to be able to find with ctrl+f.

Kurloc avatar Aug 14 '20 21:08 Kurloc

A note below, "To send data to clients, call send_event:", that says, "send_event() must be called from ASGI in production. Calling send_event() from uwsgi will cause messages to go no where without error.", would probably help :)

I run the same setup, including nginx + uwsgi and events views redirected to daphne. You need to install django-grip and a GRIP proxy like pushpin which will manage routing the events from your uwsgi processes to the proper channels. It works and there is a line in the docs that suggests as much. ;)

oruehenbeck avatar Feb 12 '21 09:02 oruehenbeck