Simultaneous Continuous Push and Pull Replication Supported in CBLite.Net?

Running one Push and one Pull replicator simultaneously and in Continuous mode. Is this supported?
Often I see this and replication doesn’t appear to be functioning:
(Looks vaguely like this old issue)

Database: Loaded Couchbase.Lite.Storage.SystemSQLite plugin. SQLite encryption functionality will not be available
Database: Couchbase.Lite.Storage.ForestDB plugin not found. ForestDB functionality will not be available
SqliteCouchStore: Initialized SQLite store (version 3.8.10.2 (2015-05-20 18:17:19 2ef4f3a5b1d1d0c4338f8243d40a2452cc1f7fe4))
Database: Using Couchbase.Lite.Store.SqliteCouchStore for db at /data/user/0/xxx/files/.local/share/smart.cblite2; upgrade=False
Thread started: Database Thread #11
Replication: Attempting to start pusher (a635bc31-db25-4a18-b1cd-7143a36ecb38)
_Replication: Beginning replication process…
Replication: No local checkpoint, not getting remote one
Replication: Attempting to start puller (bb6568ed-c53d-4af0-ad6b-9b3d09b9577e)
Replication: Beginning replication process…
Replication: No local checkpoint, not getting remote one

Replication
Http Message failed to send: Method: PUT, RequestUri: ‘http://104.208.165.171:4984/sync_gateway/_local/f8033b5ba849f3482cb23153a71ae31176b2ab86’, Version: 1.1, Content: System.Net.Http.ByteArrayContent, Headers:
{
Accept: multipart/related, application/json
User-Agent: CouchbaseLite/1.2 (.NET Huawei Nexus 6P API23/arm64-v8a 1.2.1/434a743)
Connection: keep-alive
Content-Type: application/json
}
Replication: Http exception
[HttpResponseException: StatusCode = Conflict]
Replication
Failed content: {“lastSequence”:“0”}
Replication: Unable to save remote checkpoint for bb6568ed-c53d-4af0-ad6b-9b3d09b9577e:
[HttpResponseException: StatusCode = Conflict]
Replication: Attempt to send a message after replicator was stopped, aborting…

Server Side:
01:12:05.634904 2016-05-26T01:12:05.634Z HTTP: #1397: --> 401 Login required (0.0 ms)
01:12:06.303914 2016-05-26T01:12:06.303Z HTTP: #1398: GET /sync_gateway/
01:12:06.303914 2016-05-26T01:12:06.303Z HTTP: #1398: --> 401 Login required (0.0 ms)
01:12:06.688921 2016-05-26T01:12:06.688Z HTTP: #1399: HEAD /
01:12:06.688921 2016-05-26T01:12:06.688Z HTTP+: #1399: --> 200 (0.0 ms)
01:12:06.701924 2016-05-26T01:12:06.701Z HTTP: #1400: PUT /sync_gateway/_local/f8033b5ba849f3482cb23153a71ae31176b2ab86 (as blackwolf393)
01:12:06.701924 2016-05-26T01:12:06.701Z HTTP: #1401: POST /sync_gateway/_revs_diff (as blackwolf393)
01:12:06.872926 2016-05-26T01:12:06.872Z HTTP: #1400: --> 409 Document update conflict (172.0 ms)
01:12:06.893280 2016-05-26T01:12:06.893Z HTTP+: #1401: --> 200 (192.4 ms)
01:12:07.094932 2016-05-26T01:12:07.094Z HTTP: #1402: GET /sync_gateway/_local/f8033b5ba849f3482cb23153a71ae31176b2ab86 (as blackwolf393)
01:12:07.094932 2016-05-26T01:12:07.094Z HTTP+: #1402: --> 200 (1.0 ms)

The conflict can happen from time to time. It means that the local DB doesn’t have the most recent version of the saved progress document that the remote has. In this situation, it will retry to download the recent version from the remote and then continue, which coincidentally looks like this:

([quote=“wilsondy, post:1, topic:8431”]
01:12:06.872926 2016-05-26T01:12:06.872Z HTTP: #1400: --> 409 Document update conflict (172.0 ms)01:12:06.893280 2016-05-26T01:12:06.893Z HTTP+: #1401: --> 200 (192.4 ms)01:12:07.094932 2016-05-26T01:12:07.094Z HTTP: #1402: GET /sync_gateway/_local/f8033b5ba849f3482cb23153a71ae31176b2ab86 (as blackwolf393)01:12:07.094932 2016-05-26T01:12:07.094Z HTTP+: #1402: --> 200 (1.0 ms)
[/quote]

Continuous push and pull are certainly supported at the same time. Can you elaborate on what you are seeing?

I thought this coincided with data not getting replicated from server side, but I haven’t done a thorough examination. So this isn’t as bad as it sounds “Replication: Attempt to send a message after replicator was stopped, aborting…” ?

Based on your comments I will more carefully check on the local vs remote db next time I see this.

That message means that an asynchronous operation was hanging around and didn’t finish until after the replication stopped, at which point it is not allowed anymore. In and of itself it is not dangerous.