These are chat archives for fanout/pushpin

15th
Jun 2018
Jorge S. Cuesta
@jorgecuesta
Jun 15 2018 15:32
@jkarneges Hi man, one quick question about routes
I see we can does * target:8080 target:8081
so target options should be following each target or at the end of targets?
* target:8080,over_http target:8081,over_http VS * target:8080 target:8081,over_http
Also one more question, pushpin will try with target:8080 first and if it don’t answer will try with target:8081 or it will send same request to both an first response is what it accept as truth
Justin Karneges
@jkarneges
Jun 15 2018 16:37
@jorgecuesta each target has its own options. it tries them in order
Jorge S. Cuesta
@jorgecuesta
Jun 15 2018 17:27
nice :)
Daniel Ram
@danieldram
Jun 15 2018 19:05
Hi there, I noticed there is a cache layer in pushpin, is there any documentation on the size of the cache and when the cache expires?
Daniel Ram
@danieldram
Jun 15 2018 19:46
I also have one more question. With regards to reducing the traffic to a pushpin node for scaling, is there a way to shard the traffic to a pushpin server similar to the way mongodb can shard requests between instances? Would this need to be done manually or is there a solution from pushpin?
Jorge S. Cuesta
@jorgecuesta
Jun 15 2018 20:11
*,proto=ws,debug=${debug},ssl=yes graphql:2026,over_http,ssl,insecure localhost:2026,over_http,ssl,insecure docker.for.mac.localhost:2026,over_http,ssl,insecure docker.for.win.localhost:2026,over_http,ssl,insecure
all
@jkarneges following my previous question about multiple targets and how it work, you told that it will try in order, but checking those logs (all from container start) it just try to contact graphql:2026 never try with others
Justin Karneges
@jkarneges
Jun 15 2018 23:08
@danieldram what cache layer are you speaking of?
you shouldn't need to shard requests. unless you're doing something sticky-ish, any pushpin instance should be able to handle any request
Justin Karneges
@jkarneges
Jun 15 2018 23:23
@jorgecuesta ah seems there's a bug. the websocket-over-http code isn't correctly indicating the reason for the error, so the proxy retry logic doesn't kick in
Justin Karneges
@jkarneges
Jun 15 2018 23:33
even when it does work (e.g. with normal http), pushpin's fallback is pretty limited. probably the better thing to do is use a load balancer behind pushpin