is this maintained? any point in filing pull requests? about synapse HOT 7 CLOSED

this project is in active use at a few places, and contributors from airbnb and yelp have commit privs. things have been a bit slow in the code review department, but documentation PRs should be fairly trivial to merge

from synapse.

just had to dig down into source to discover what #112 already addresses

from synapse.

@chrono,
@jnb and I from Yelp plan to help maintain this going forward along with @igor47 and the airbnb crew.

Right now we're concentrating on getting the Yelp forks of nerve/synapse merged back into upstream as they have a lot of important reliability fixes for multi-datacenter setups (connection pooling, removal of fast fail in nerve, allowing synapse to reconfigure more aggressively than it restarts, etc ...). Once we do that we're going to start going through pull requests and working with @igor47 to get everything tidied up.

from synapse.

+1. Maybe you could give a few community members commit access if airbnb doesn't have the bandwidth to support this?

FWIW, here was my experience trying it out with a super simple config, maybe it'll help anyone coming here in the future before these issues get addressed. It crashes when I start it because

• In the global haproxy section, shared_frontend needs to be a list not a string (already in #112 as @chrono mentioned)
• method: stub is not a thing, it needs to be "base" (link)

Now I can launch synapse and it stays running and logs that it is writing the haproxy config. It is not, the config silently never gets written. The README says that the global haproxy option do_writes defaults to true but it doesn't, anything that's not explicitly set in my config is not present in the options hash in the Haproxy object when synapse runs so everything defaults to false.

Now it's finally running as expected for my simple example.

Unrelated, @jolynch when you say you have a fix for "allowing synapse to reconfigure more aggressively than it restarts" is that the same thing described in #78?

from synapse.

@dcosson Yes our fork does help mitigate that problem, but it is not a complete solution. Basically we cache synapse state locally for 30m and will always put cached backends in regardless of if they are in zookeeper (if we don't know about them in zookeeper they go in disabled). Then because our fork can reconfigure (but not restart) every loop of the main loop we can enable them via the stats socket as soon as they report up.

It doesn't totally solve the problem, but we've seen a significant decrease in 503s related to restarts since we rolled it out. That being said we're still dogfooding internally and have found a bug or two. The next step is putting them in as backups automatically (that should solve your problem).

I'm pushing internally to get our forks merged back. We're waiting for a 2 week period of zero bugs in production before we go ahead and merge them in.

from synapse.

@jolynch cool to hear. Thanks for the update

from synapse.

@chrono If you find any more issues with the documentation please re-open an issue or PR and we can fix it. I've been trying to fix it up and merge PRs as I see issues.

I'm working with @dcosson to merge #126 which will resolve #98

from synapse.