“subscribe-user” fails when run on nginx+wsgi with django-websocket-redis

[panicz]

I have an instance of django-websocket-redis, installed from pip and configured according to the instructions, that is, I have an instance of nginx and two instances of uwsgi, configured to communicate with nginx via websockets.

Everything seems to work fine when I use websockets with the broadcast option, i.e.

RedisPublisher(faculty=x,broadcast=true).publish_message(RedisMessage(y))

and

ws://{{ host }}/ws/x?subscribe-broadcast&echo

However, when I try to send messages to specific users, i.e.

RedisPublisher(faculty=p, users=[u]).publish_message(RedisMessage(q))

and

ws://{{ host }}/ws/p?subscribe-user&echo (being logged in as user u)

then I get no message at all.

This latter setup works when the django ./manage.py runserver is used instead of nginx + uwsgi.

Could anyone explain what could be the reason of this discrepancy, and how I could possibly fix it?

Thanks in advance

[jrief]

This is likely a bug and a duplicate of #56. I will check as soon as I have some time, next week. Thanks for for report.

[papasax]

I have exactly the same issue. On Chrome i get this error message on this instruction:

ws = new WebSocket(url);

WebSocket connection to 'ws://www.mysite.com/ws/channelr?subscribe-user' failed: One or more reserved bits are on: reserved1 = 1, reserved2 = 0, reserved3 = 0

[papasax]

I tried subscribe-session, and this time i get this error, even in development env. "One or more reserved bits are on: reserved1 = 0, reserved2 = 1, reserved3 = 0"

[jrief]

In order to ease troubleshooting, I added a reference implementation for this project: http://websocket.aws.awesto.com/

this implementation runs on a AWS EC2 instance using one nginx with two separate (one for the Django loop, one for the WS loop) uwsgi instances. The running code is exactly the same, as you find in the repository.

It turned out that #56 was a configuration error, because the issuer of the bug did not read the documentation carefully.

Therefore, first try to get the supplied example up and running.

[khamaileon]

@papasax

I had the same problem. subscribe-session failed because request.session didn't exists when the websocket initialized.

def _wrap_sessions(sessions, request):
    """
    Returns a list of session keys for the given lists of sessions and/or the session key of the
    current logged in user, if the list contains the magic item SELF.
    """
    result = set()
    for s in sessions:
        if s is SELF and request:
            result.add(request.session.session_key)
        else:
            result.add(s)
    return result

I invite you to add 'console' in your django logging settings to see when the error occured:

'django.request': {
    'handlers': ['console', 'mail_admins'],
    'level': 'ERROR',
    'propagate': False
},

I don't know how to solve this for now.

[ikks]

A running project on Ubuntu with nginx 1.7.10-1chl1

Django==1.6
uWsgi==2.0.6
django-redis-sessions==0.4.0
django-websocket-redis==0.4.1

was upgraded to Django==1.7, we tried updating django-websocket-redis to 0.4.2 and master, changed uWsgi to 2.0.3 and 2.0.9 but none of the combinations worked

We got errors on the log like:

2015/02/12 17:37:43 [error] 11229#0: *11 upstream sent no valid HTTP/1.0 header while reading response header from upstream, client: ,  request: "GET /notificaciones/main?subscribe-user HTTP/1.1", upstream: "http://unix:///tmp/websocket.sock:/notificaciones/main?subscribe-user"

meanwhile the clients show messages like

 failed: Error during WebSocket handshake: Invalid status line
main.min.a0f614466a16.js:342 Websocket connection is broken!

@jrief can you confirm if http://websocket.aws.awesto.com/ is running in Django==1.6 or 1.7?

[jrief]

It currently runs on django-1.6, but that's not your problem. Presumingly one of the parts between your browser and Django, does not support the Websocket extensions added to HTTP/1.1

[ikks]

Confirmed, we used exact the same infrastructure with Django 1.6 and it worked, switched to Django 1.7 and did not work. :( . For now we are sticking to Django 1.6 in that project.

[camilonova]

I just hit the same issue with:

celery==3.1.17
Django==1.7.4
django-websocket-redis==0.4.1
gevent==1.0.1
greenlet==0.4.5
redis==2.10.3

To make it work I have reverted the libraries to:

celery==3.1.17
Django==1.6.10
django-websocket-redis==0.4.1
gevent==1.0.1
greenlet==0.4.5
redis==2.10.3

As you can tell the only difference is the Django version. When I do runserver using Django 1.7 on my dev machine works fine, but as soon it goes to production it starts failing.

What I saw doing some debugging was that the call to ?subscribe-user was returning (Opcode -1).

Please let me know how else we can work together to fix this.

Thanks

[jrief]

OK, then this seems to be a bigger issue. Will try with Django-1.7 next week.

[camilonova]

@jrief Thank you, please let me know if I can do something to see this fixed soon.

[tarunbehal]

@jrief any update on this issue.?

[maratsuponitsky]

@jrief please provide any information about this issue. I'm using django 1.8 and got the same error.

[tarunbehal]

@maratsuponitsky I got it working on Django 1.7 using below configurations:

[uwsgi]
master=True
http-websockets=true
gevent=1500
workers=5
socket=web.sock
stats=stat.sock
virtualenv=/path to env/
die-on-term=true
module=wsgi
chmod-socket=777
buffer-size=32768
chdir=/app dir/
processes=3
memory-report=true
no-orphans=true```

But there are few issues with this
1. some messages might get skipped
1. the connection closes every 3 sec or so.

Mr @jrief We all would highly appreciate if you can test the application with Django 1.7+ and provide a sample configuration of uwsgi and nginx... awaited response.

[camilonova]

Django 1.6 and django-websocket-redis==0.4.4 fails the same.

Using django-websocket-redis==0.4.1 works.

[Rockly]

I have found the reason why my project raise that issue. I used wireshark to understand which flag is raised and as it seem, and I found this weird string "Models aren't loaded yet". This is an actual Django exception. Long story short on some configuration exceptions are been leeked to the websocket stream. Which is both an annoying bug to find and a security issue (maybe DEBUG will do no such thing, didn't check)

I simply fix my error but new errors may join in the future

[camilonova]

@jrief Did you tried with Django 1.7?

We should better make sure it works with Django 1.8 LTS

[ArtemBernatskyy]

Any progress ? I am using Django 1.9...