sweet lmk once you've enabled it

what timezone are you in?

will do

pacific

cool*

ah looks like can't enable forking because it's private

maybe push the repo to your own origin? (i.e. manual fork)

sure, I can do that

alright, deploying with multi-node enabled. Do you think that would actually stop the error I'm seeing?

hah it might.. though, this is a real timing issue with disconnection states. I'm looking at resolving

lol ya I figured it wouldn't solve the original problem with the socket but maybe just circumvent it

yeah it should get around it, redis uses a publisher and it won't panic

alright back up now

{"level":"info","ts":1611708658.1222212,"caller":"server/main.go:145","msg":"configured key provider","num_keys":1}
{"level":"info","ts":1611708658.2630804,"caller":"server/main.go:178","msg":"using multi-node routing via redis","address":"livespot-lk-redis-production:6379"}
unable to connect to redis: dial tcp 100.67.129.128:6379: connect: connection refused
{"level":"info","ts":1611708679.9268491,"caller":"server/main.go:145","msg":"configured key provider","num_keys":1}
{"level":"info","ts":1611708680.067002,"caller":"server/main.go:178","msg":"using multi-node routing via redis","address":"livespot-lk-redis-production:6379"}
{"level":"info","ts":1611708680.0961013,"caller":"service/server.go:100","msg":"starting LiveKit server","address":":7880","nodeId":"ND_0000000000000000"}

perfect, that should help me for now

awesome!

With mutli-node it seems this issue still plagues me

Except this time the behavior is different. 1. Client attempts to open websocket connection 2. Server logs

{
  "level": "info",
  "ts": 1611709273.0404878,
  "caller": "service/rtcservice.go:92",
  "msg": "new client connected",
  "room": "RM_pXmT5VY2q2vqChAQ3tDLym",
  "roomName": "8fb5bc1e-1918-4240-9e05-b1c01420152c",
  "name": "WzEsICJwdWJsaWMiLCAidXNlciIsICIweGM5ZTk0NjQ3NDg4NTJFQWZDMDlFOGM1MkEwZTA5MjQwQkFmYUMyNUMiXQ=="
}

3. Client hangs waiting for socket connection to open

I've been refreshing the page to close the socket which results in the server logging:

{
  "level": "info",
  "ts": 1611709408.9634256,
  "caller": "service/rtcservice.go:110",
  "msg": "WS connection closed",
  "participant": "WzEsICJwdWJsaWMiLCAidXNlciIsICIweEZGQzgwYmQyQTQxM2YzN0UxMjVEMzlDMjgxQ2M4NUI4OGRjZWJGMjAiXQ=="
}

so with #3, the client hangs?

yes waiting for the socket to emit an

onopen

event

it seems with single node, it was panicking when client disconnected abruptly..

but the client was able to connect right?

let me recreate that and see what happens on disconnect

in single-node? yes

yes.. ok

but with multi-node, client is hanging before connecting?

in single-node the only time the client would fail to connect is after the

panic: send on closed channel

event occurs in the server because then the server responds with

503

to all requests

yes, that is straight forward to resolve. I'm more concerned about the hanging for multi-node

in single node there is no response from the server to signal that the connection was accepted

you saw the acknowledgment from the server in the logs, on the client side this is what you see