On Jul 15, 2014, at 5:16 AM, Andrew <[email protected]> wrote:
> The failure appears to happen when the replication is idle for more than 5 > minutes. From examining the logs at both ends, it seems that CBL is not > reliably detecting that a WebSocket has closed and just sits there waiting > for more updates (which, without a WebSocket, never arrive). > This sounds sort of like issue #335, where the retry interval for the WebSocket connection doesn't reset after a successful connection (which was fixed a few days ago), but you say that CBL never retries? What I'm suspecting (see below for why) is that something's wrong with connectivity between CBL and the Gateway -- packets aren't making it through. What's the network environment like? > 1. Is the Sync Gateway deliberately closing the WebSocket after 300 seconds > and is this normal behaviour when replication is idle? (From looking at the > code, I would say yes, this is the default timeout). > The _changes options are sort of confusing and I just checked with the CouchDB docs to refresh my memory. The ?timeout= parameter will close the connection if no events are sent in that interval; but the ?heartbeat= parameter "overrides any timeout to keep the feed alive indefinitely." (Note the "else" at changes_api.go:223.) CBL always specifies a heartbeat, so the timeout should never occur. Now, the heartbeat used by CBL is 300 seconds (CBLChangeTracker.m:27). If the gateway is notifying that the WebSocket connection closed after 300 seconds, what's likely happening is that connectivity to the client was lost -- it sent a heartbeat (an empty message) and never got a TCP ACK packet in response, so the kernel closed the socket. > 2. Why is CBL unreliably detecting the socket closure and allowing the > replication to silently fail with no retry? And why does switching on WS > logging appear to help? > Well, in a situation where connectivity is lost, TCP only detects the problem when it tries to send data and doesn't get an ACK. I think that the WebSocket client code is in a state where it's just waiting passively for messages to arrive, so it doesn't send data on its own and the socket won't realize something's wrong. (IIRC, TCP will eventually send a packet after a long idle time, but it's something like 90 minutes.) --Jens -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/4F0391C0-F88D-4645-AB06-DCC84E2878CB%40couchbase.com. For more options, visit https://groups.google.com/d/optout.
