Q: Continuous replicator halt, the sync stop

my env:
cb 6.0.1
sg :2.1
cb lite: 2.5

I using android developing a program. I declare a global instance of replicator, and set the coutinuous is true. couchbase lite work for me about 15 mins, then it stop sync data. the android logcat is:

2019-05-28 11:45:20.198 10091-13100/com.kitchenmanage.kitchenmanage W/CouchbaseLite/NETWORK: WebSocketListener.onFailure() response -> null: java.net.SocketException: Connection timed out
2019-05-28 11:45:20.198 10091-13100/com.kitchenmanage.kitchenmanage I/CouchbaseLite/NETWORK: {N8litecore4repl12C4SocketImplE#55}==> N8litecore4repl12C4SocketImplE ws:// @0x74581f1e30
2019-05-28 11:45:20.198 10091-13100/com.kitchenmanage.kitchenmanage I/CouchbaseLite/NETWORK: {N8litecore4repl12C4SocketImplE#55} Socket disconnected! (reason=1, code=104)
2019-05-28 11:45:20.198 10091-13100/com.kitchenmanage.kitchenmanage I/CouchbaseLite/NETWORK: {N8litecore4repl12C4SocketImplE#55} sent 1603 bytes, rcvd 825, in 1428.272 sec (1/sec, 1/sec)
2019-05-28 11:45:20.199 10091-12220/com.kitchenmanage.kitchenmanage W/C4Socket: C4Socket.dispose() handle -> 499694640944
2019-05-28 11:45:20.200 10091-12220/com.kitchenmanage.kitchenmanage I/CouchbaseLite/NETWORK: {N8litecore4blip10ConnectionE#22} Closed with errno 104: Connection reset by peer

sync gateway logs don’t have any error. the sync stop, the device can’t sync any data. the sync gateway log is:

2019-05-28T11:14:55.449Z [INF] HTTP: #006: --> 401 Login required (1.1 ms)
2019-05-28T11:14:55.720Z [INF] HTTP: #007: GET /test/_blipsync (as 5d13d217)
2019-05-28T11:14:55.720Z [INF] HTTP+: #007: --> 101 [60a7a095] Upgraded to BLIP+WebSocket protocol. User:5d13d217. (0.0 ms)
2019-05-28T11:14:55.720Z [INF] WS: c:[60a7a095] Start BLIP/Websocket handler
2019-05-28T11:14:55.754Z [INF] SyncMsg: c:[60a7a095] #1: Type:getCheckpoint Client:cp-y1Mmvg2wRyYOc28GPdFYi1pMDpo= User:5d13d217
2019-05-28T11:14:55.808Z [INF] SyncMsg: c:[60a7a095] #2: Type:subChanges Since:93230 Continuous:true Filter:sync_gateway/bychannel Channels:5d13d217 User:5d13d217
2019-05-28T11:14:55.809Z [INF] Sync: c:[60a7a095] Sending changes since 93230. User:5d13d217
2019-05-28T11:14:55.809Z [INF] Changes: c:[60a7a095] MultiChangesFeed(channels: {5d13d217}, options: {Since:93230 Limit:0 Conflicts:false IncludeDocs:false Wait:true Continuous:true Terminator:0xc00021a3c0 HeartbeatMs:0 TimeoutMs:0 ActiveOnly:false Ctx:context.Background.WithValue(base.LogContextKey{}, base.LogContext{CorrelationID:"#007"}).WithValue(base.LogContextKey{}, base.LogContext{CorrelationID:"[60a7a095]"})}) … (to 5d13d217)
2019-05-28T11:14:55.810Z [INF] Cache: Initialized cache for channel “5d13d217” with options: &{ChannelCacheMinLength:50 ChannelCacheMaxLength:100 ChannelCacheAge:1m0s}
2019-05-28T11:14:55.810Z [INF] Cache: c:[60a7a095] getCachedChanges(“5d13d217”, 93230) --> 0 changes valid from #93237
2019-05-28T11:14:55.810Z [INF] Cache: Querying ‘channels’ for “5d13d217” (start=#93231, end=#93237, limit=0)
2019-05-28T11:14:55.835Z [INF] SyncMsg: c:[60a7a095] #3: Type:proposeChanges #Changes: 1 User:5d13d217
2019-05-28T11:14:55.892Z [INF] Cache: Got no rows from query for channel:“5d13d217”
2019-05-28T11:14:55.892Z [INF] Cache: c:[60a7a095] GetChangesInChannel(“5d13d217”) --> 0 rows
2019-05-28T11:14:55.892Z [INF] Sync: c:[60a7a095] Sent all changes to client. User:5d13d217
2019-05-28T11:14:55.915Z [INF] CRUD: c:[60a7a095] Stored doc “Table.130ba860-beb4-4b2d-a930-0d071cb0e589” / “229-b8fd931c434a828a2d3def2567fe686e2f82d69f” as #93237
2019-05-28T11:14:55.916Z [INF] Cache: Received #93237 after 5ms (“Table.130ba860-beb4-4b2d-a930-0d071cb0e589” / “229-b8fd931c434a828a2d3def2567fe686e2f82d69f”)
2019-05-28T11:14:55.916Z [INF] Cache: Initialized cache for channel "" with options: &{ChannelCacheMinLength:50 ChannelCacheMaxLength:100 ChannelCacheAge:1m0s}
2019-05-28T11:14:55.916Z [INF] Cache: #93237 ==> channels {
, 5d13d217}
2019-05-28T11:14:55.916Z [INF] Cache: c:[60a7a095] getCachedChanges(“5d13d217”, 93230) --> 1 changes valid from #93231
2019-05-28T11:14:55.955Z [INF] SyncMsg: c:[60a7a095] #5: Type:setCheckpoint Client:cp-y1Mmvg2wRyYOc28GPdFYi1pMDpo= Rev:0-250 User:5d13d217
2019-05-28T11:14:55.998Z [INF] Sync: c:[60a7a095] Sent 1 changes to client, from seq 93237. User:5d13d217
2019-05-28T11:14:56.082Z [INF] SyncMsg: c:[60a7a095] #6: Type:setCheckpoint Client:cp-y1Mmvg2wRyYOc28GPdFYi1pMDpo= Rev:0-251 User:5d13d217
2019-05-28T11:15:11.121Z [INF] Import: Created new rev ID for doc “Table.130ba860-beb4-4b2d-a930-0d071cb0e589” / “230-03dcc70487116dc1eea74c47be453205”
2019-05-28T11:15:11.130Z [INF] CRUD: Stored doc “Table.130ba860-beb4-4b2d-a930-0d071cb0e589” / “230-03dcc70487116dc1eea74c47be453205” as #93238
2019-05-28T11:15:11.133Z [INF] Cache: Received #93238 after 8ms (“Table.130ba860-beb4-4b2d-a930-0d071cb0e589” / “230-03dcc70487116dc1eea74c47be453205”)
2019-05-28T11:15:11.133Z [INF] Cache: #93238 ==> channels {*, 5d13d217}
2019-05-28T11:15:11.133Z [INF] Cache: c:[60a7a095] getCachedChanges(“5d13d217”, 93237) --> 1 changes valid from #93231
2019-05-28T11:15:11.202Z [INF] Sync: c:[60a7a095] Sent 1 changes to client, from seq 93238. User:5d13d217
2019-05-28T11:15:11.274Z [INF] SyncMsg: c:[60a7a095] #7: Type:setCheckpoint Client:cp-y1Mmvg2wRyYOc28GPdFYi1pMDpo= Rev:0-252 User:5d13d217
2019-05-28T11:15:45.785Z [INF] HTTP: #008: GET /test/_config (as ADMIN)
2019-05-28T11:15:45.788Z [INF] HTTP+: #008: --> 200 (3.0 ms)

I use wireshark catch the network package, the result is:

so I use a Stupid way that when having not sync data coming in for 2 mins, I’ll stop the cb lite replicator and start it. then replicator can sync data for me.

the replicator stop purpose for save the server resource?
how can I get the replicator status when it’s stop? it often became BUSY status, and don’t become IDLE.

Thanks for your reply!

The indicated error is that the connection was reset by the machine Sync Gateway is running. You should examine any proxies or firewall rules that you have in place that might be messing with the ability to stay connected.

HI @borrrden,

Thanks for you reply. I also think this issue is network .
when this case occurred, why restart replicator can resolve this issue?
can I using replicator stop and start method to resolve this issue ?
I find config about replication for sync gateway:

must set this property for sync gateway continuous sync?

thanks again.

No this property is irrelevant to syncing with Couchbase Lite. I can’t say why a restart would fix the issue as networks are complicated and I have no details about yours. My first guess is that the other side is cutting off long opened connections because it feels like they are not valid.

HI @borrrden,

thanks, I’ll inspect my server network env.


You’ve mentioned in other threads that there’s a gateway/proxy of some kind between the client and SG; that seems to be where the problem is. For some reason it stops transmitting data.