couchDB: checkpoint_commit_failure -

I have a couchDB server running on the AZON ec2 instance. This is 1.2.0 from RPM.

I have several Android devices that run Couchbase-Mobile 2.0.

These devices start a constant push and draw replication from the server. All these devices should eventually be compatible.

However, when one of the mobile devices pushes a document, when another mobile device tries to drag this document, I get the following error on the device log: < Pre> e / couchdb (9896): [error] [& lt; 0.199.0 & gt;] Replica `bf69ede4416770a1fef28ffb4c4e6950 + constant (` treatment '- & gt; `http: // portecTest: *** ** 50.150.250.165: 5984 / treatment /`) failed: {checkpoint_commit_failure, & lt; "Error updating target checkpoint document: conflict" & gt; & Gt;}

The way this app is designed, this document will not be edited by other devices or servers, so this modification is not amended.

After this, no other document will repeat, push or pull, until I restart the app (continuous replication is started when the app starts). After restarting, it works.

What does this mean? Any thoughts that can cause it?

I have seen it because of replication replication id. / P>

When you set up a replica in the _replicator database, a _replication_id field is added to the document (such as bf69ede4416770a1fef28ffb4c4e6950 + continuous, for your current replication). On the two ends of the replication process, using a document on http: // server: 5984 / dbname / _local / replication-id is used by the replication process to track the process of replication Recording of things like sequence number, and last seen.

This is also used to spots, if you have two replicas set to do the same job, because the ID is generated completely by the parameters, so two replicas are the same goal and The source will be the same ID, and there will be no other option.

I am not sure how the replication_ID has originated (maybe there is some kind of seed anywhere?) But I certainly had problems earlier than this, in which it was equally Was generated (including a replication docs like {source: localDb, target: remoteServer: 5984 / remoteDb} ), so all those attempts made use of the same db / _local / id document To do this, and then to throw a lot of conflicts Because they were a changed document on all remote servers simultaneously.

You can check whether these are the problem by comparing the _replication_id field on both mobile devices and seeing if they are .

I decided to include the address of the local machine in the source so that each ID is different, and the conflict has gone away. This can not be practical with mobile devices for you, as long as you can get continuous local addresses working on each mobile (some generated hostname?) I could not find any way to set up replication_id manually.

If this is the problem, the solution is basically to make each replication document unique in some way from others. Can you name the database on different mobile devices on any mobile device?