These are chat archives for fanout/pushpin

17th
Apr 2017
Justin Karneges
@jkarneges
Apr 17 2017 02:18
hi @Paratron , what version are you using? before 1.15 there were some edge cases where DISCONNECT might not get sent
you might test with a non-browser client as well (e.g. wscat) to see if this might be an issue in the browser not immediately cleaning up connections
Christian Engel
@Paratron
Apr 17 2017 12:10
It seems like Chrome (at least) does not close a websocket connection when you close the browser tab and/or quit the browser.
I have now created a workaround with listening to window.onbeforeunload and call websocket.close() within that event handler.
Need to test if Firefox and/or IE behave the same
Justin Karneges
@jkarneges
Apr 17 2017 17:19
the connection should definitely close when you quit the browser. I'm not sure how it couldn't, unless there's a background chrome process
we should look at the pushpin logs. open a connection and quit the browser, then send me m2adapter.log
larshelg
@larshelg
Apr 17 2017 17:53
@jkarneges I've been pulling my hair out trying to set up two pushpin instances communication with my backend using zeromq. Everything is working fine with one instance, following the "example without a webserver" from pushpins github page. The problem seems to be how pushpin is handling the req socket. Setting sock.connect('tcp://127.0.0.1:10000') works but sock.bind('tcp://*:10000') (using bind with a wildcard) just hangs and end up after a while with http://localhost:7999/ -> zhttpreq/tcp://127.0.0.1:10000 code=502 in the pushpin-proxy log.
Setting up a simple server/client example (no pushpin) using python using sock.bind('tcp://*:10000") is working fine.
Justin Karneges
@jkarneges
Apr 17 2017 19:36
pushpin uses bind, so handlers must connect
if you have multiple pushpin instances on the same server, then you'll need to be sure the binds don't conflict
and the handler must connect to both
Christian Engel
@Paratron
Apr 17 2017 22:39
@jkarneges Afaik the websockets spec requires a websocket connection to send a few bytes to be closed correctly
If you just quit chrome or close the tab, those bytes are not sent
chrome will simply cut the TCP connection
this should result in a timeout at some timt
*time
but I have no idea how pushpin handles that
larshelg
@larshelg
Apr 17 2017 22:59
@jkarneges Ok, thanks! So i have to use connect on my handlers. So if I have two servers with pushpin and only one backend server, then the handlers must connect to both? Then i would have to redeploy my backend if i add an extra pushpin server, if I understand correctly.
Justin Karneges
@jkarneges
Apr 17 2017 23:10
@larshelg that's correct
the need to reconfigure your backend when pushpin instances are added is typical, since you need to publish to the new instances as well
Justin Karneges
@jkarneges
Apr 17 2017 23:16
@Paratron cutting the tcp connection should cause pushpin to send DISCONNECT. if that's not happening, then it's a bug
clean close produces the CLOSE event