On Tuesday, July 15, 2014 5:44:42 PM UTC+1, Jens Alfke wrote: > This sounds sort of like issue #335 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fcouchbase%2Fcouchbase-lite-ios%2Fissues%2F335&sa=D&sntz=1&usg=AFQjCNH5bxk4uJpTdlJP88DXlKJgMX1_3Q>, > > 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? >
Yes I'm familiar with that issue, but I think it's separate. With #335, CBL sees the disconnect correctly but just incorrectly keeps waiting for longer before retyring. With our case, it never gets that far - it *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? > App running in the iPad simulator -> NAT router -> high-speed fibre -> internet -> AWS EC2 instance (Ubuntu). The connection is pretty robust to be honest. 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. > I guess it's possible that something along the way (NAT router or AWS maybe) is actively involved in the socket and is hauling down what it considers to be an inactive connection/translation. If it were running to the same 300 second timeout, it would possibly explain why sometimes the Sync Gateway connection closed message gets through to CBL and sometimes it doesn't. Is there any way of adjusting the Sync Gateway heartbeat without rebuilding it to see if that's the case? .. 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.) > Ah. But, more generally, isn't that exactly what CBL should be managing? By definition, it's going to be running on devices that are likely to have less than perfect connections. In that scenario, the passive WebSocket mode, where CBL takes no responsibility for checking the connection or attempting its own heartbeat, seems destined to go horribly wrong at some point! Or am I missing something obvious? -- 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/e082221d-2022-48ef-aa1a-14f13a973f04%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
