We are seeing web socket connections being closed intermittently when using the changes feed. I notice there is a “maxHearbeat” setting in the sync gateway config file with a description of “Maximum heartbeat value for _changes feed requests (in seconds).”
Is this the interval at which the sync gateway will send heartbeats to all web socket connections? Is there a default value? Are there other settings I should be looking at to keep web socket connections alive?
Do you have any middleware between SG and the clients? Load balancers, nginx, AWS … ? There are a lot of things that will “helpfully” close idle sockets after some time interval.
Generally it’s the client that specifies the heartbeat in a changes request. Current versions of Couchbase Lite set reasonable values for this. Maybe one of the Sync Gateway engineers can describe what that config setting is for.
Confirming what @jens said, the parameter in the SG config controls the maximum a client can request for a heartbeat. If you don’t specify, there’s no limit.
So the current implementation requires the client to set the heartbeat time. I believe the default with replications is 30s. You can control that on replications.
If you write a _changes feed listener to access SG API directly, you can set the heartbeat with the heartbeat parameter. There’s an example in this blog post.
Will that work for you?
I have specified a 30s heartbeat from our client (not CBLite) in the web socket/_changes feed request. If a heartbeat value greater than 30s is requested, and the sync gateway config for maxHeartbeat is 20 seconds, does the request get rejected when submitted by the client? Or does the server default to a different value?
I have it set to 20 sec and I open websocket connection and also ping it every minute, still connection closes after 5 min, I re-open it, and it is always after 5 min that it gets closed.