907407 - Stackato not reverse proxying websocket connections.

Status: RESOLVED WONTFIX

(Infrastructure & Operations :: IT-Managed Tools, task)

Description

[(not reading bugmail) Nick Desaulniers [:\n]]

I'm trying to run an application that uses websockets and the websocket protocol (we://) on stackato but I'm not able to establish connections.  This article [1] seems to place the blame on nginx not reverse proxying websocket messages.  This article [2] shows how to whip up a simple WS server, if you know Node.js.  You can then connect to it by running from the web console `new Websocket("ws://app-name.allizom.org:port/")`

[1] http://www.activestate.com/blog/2012/09/rocking-it-stackato-and-websockets
[2] http://socket.io/

Comment 1

[Chris Turra [:cturra]]

i have enabled router2g in the dev paas. can you please try your nodejs application again and let me know how you make out?

stackato@stackato-admin1:/home/cturra$ kato config cluster --append alternative_processes router2g
WARNING: Adding alternative process "router2g" will stop the following processes...
    10.22.94.21      router
    10.22.94.21      nginx
Continue? [N/y] y
stopping router...                  ok
stopping nginx...                   ok
starting router2g...                ok
[
  "router2g"
]

Comment 2

[Chris Turra [:cturra]]

welp. that didnt work very well - everything started returning 404s so i have reverted this change. time to chat with the fine folks over at activestate about this.

Comment 3

[Chris Turra [:cturra]]

i found this in /s/logs/router2g.log:

{"level":"info","message":"Stackato router is now running","timestamp":"2013-08-20T22:55:56.470Z"}
{"level":"info","message":"Stackato-router worker ID: 1 now online","timestamp":"2013-08-20T22:55:56.504Z"}
{"level":"info","message":"Stackato-router worker ID: 2 now online","timestamp":"2013-08-20T22:55:56.521Z"}
{ [Error: connect ECONNREFUSED]
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect' }
close
{ [Error: connect ECONNREFUSED]
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect' }
close

Comment 4

[Chris Turra [:cturra]]

i was able to sort this out with lorned from activestate. i have started the router2g process again. :\n can you please try giving your application another test for me?


stackato@stackato-admin1:~$ kato config cluster --append alternative_processes router2g
WARNING: Adding alternative process "router2g" will stop the following processes...
    10.22.94.21      router
    10.22.94.21      nginx
Continue? [N/y] y
stopping router...                  ok
stopping nginx...                   ok
starting router2g...                ok
[
  "router2g"
]

stackato@stackato-admin1:~$ kato status router2g
PROCESS              STATE
---------            -------
router2g             RUNNING

Comment 5

[(not reading bugmail) Nick Desaulniers [:\n]]

Well, the static assets are being served about an order of magnitude faster now, but something is still not quite right.  I'll have to simplify my test case to see if it's me or stackato.

Comment 6

[Chris Turra [:cturra]]

sadly it looks like the change to use `router2g` has cause way too many instabilities with the system that was previously working. see bug 910931 as an example. i have reverted to the default `router` and if it solves these other bugs am going to have to stick with it for platform stability until we can upgrade to stackato 2.10.x.

i will keep this bug posted as i know more.

Comment 7

[Chris Turra [:cturra]]

looks like there is bad news for websockets in our dev paas. until we can update to 2.10, i need to keep the default router enabled to support the many other teams/app using this environment. clearly router2g wasn't ready for "prime time" in 2.6.

bug 910931 is an example of why i had to make this choice. sorry for the inconvenience :\n

Comment 8

[Mark Côté [:mcote]]

I've been told WebSockets support should be possible now that dev paas has been upgraded.  Just wanted to note my interest in this; I tried setting up a tornado websocket server via paas, but, while it appeared to connect, data wasn't being transferred properly.

Comment 9

[Chris Turra [:cturra]]

i suspect we'll need to do some work on the load balancers to support this completely. it's something on my radar - lets keep this bug open to track that.

Comment 10

[Chris Turra [:cturra]]

moving back to the unassigned queue as i am leaving mozilla. this is a tracker to evaluate with a stackato platform upgrade.

Comment 11

[Ryan Watson [:w0ts0n]]

So this bug hasn't been touched for over 7 months and I believe this service is EOL. I don't think Webops will be working with this product anymore and thus I'm inclined to timeout.