conflict causes revisions to grow without limit #1127
Comments
yonahforst
changed the title
|
I expect you do have a conflict here - the restarted helloCBL will create a new revision branch starting from a new root, since it doesn't find the matching rev numbers in the other (already pruned) branch. That new branch is preventing pruning of the larger branch, as the pruning algorithm only prunes beyond the lowest non-deleted leaf rev generation count. Resolving the conflict (marking the leaf node as deleted in the newly created branch) would allow pruning to complete as usual. I believe this is the expected behaviour of the current pruning algorithm. In general, effective pruning also requires conflicts to be resolved. If you've got a scenario where conflicts like these aren't able to be resolved/tombstoned, share the details and we can see whether there are any refinements possible to the pruning algorithm. |
|
Possibly related to #961. |
|
@adamcfraser thanks for the explanation. I'm resolving the conflicts on the device but when I try to push to sync_gateway it throws could be related to #1007 |
|
I've flushed the db and I'm no longer seeing this issue. Closing... |
|
Re-opening since there may still be things to get to the bottom of |
|
I'm having the same problem. I first saw a sync problem, then a high CPU usage on the sync_gateway's node (we're in test mode with only 4 ipads and it takes more than 50% of CPU). That's why I opened logs and saw this panic issue. The problem occurs when there's a lot of revisions, for example 5000 on a single document. When the panic occurs, the replication fails, and devices are not synced. Here's my configuration :
Here's my sync_gateway config file : {
"interface":":4984",
"adminInterface":":4985",
"log": ["Access"],
"databases": {
"database": {
"server":"http://x.x.x.x:8091/",
"bucket":"default",
"revs_limit":20,
"users": {
"GUEST": {"disabled": true, "admin_channels": ["*"]}
},
"sync":`
function (doc, oldDoc) {
if (!doc.owner) throw({forbidden : "Documents must have a owner"});
var documentForOwner = 'documentFor_' + doc.owner;
var restaurantForOwner = 'restaurantFor_' + doc.owner;
var channels = [documentForOwner];
var restaurantTypes = [
'Account',
'Item',
'LiveTillID',
'Option',
'Person',
'Till'
];
// route channels
if (restaurantTypes.indexOf(doc.type) !== -1) {
channels.push(restaurantForOwner);
}
else {
if (!doc.tillID && !oldDoc.tillID) {
throw({forbidden : "Documents must have a tillID"});
}
else {
var tillChannel;
if (doc.tillID) {
tillChannel = 'till_' + doc.tillID;
}
else {
tillChannel = 'till_' + oldDoc.tillID;
}
channels.push(tillChannel);
}
}
if (doc.type === 'LiveTillID') {
var tillChannel;
if (doc.tillID) {
tillChannel = 'till_' + doc.tillID;
}
else {
tillChannel = 'till_' + oldDoc.tillID;
}
access(doc.owner, tillChannel);
}
if (doc.type === 'Restaurant') {
access(doc.owner, restaurantForOwner);
}
channel(channels);
}
`
}
}
}As you can see there's no bucket shadowing. Here's the known panic message : This could be related to #807 ? @snej do you think this problem could come from couchbase-lite-ios or is it only a sync_gateway issue ? |
|
In addition, couchbase-lite-ios throws this error : |
|
Ok I saw in file const DefaultRevsLimit = 1000That explains why errors comes quickly when in my config file I set : ...
"revs_limit":20,
...And why the problem comes when there is more than 1000 revisions when I remove that line. What are known issues to set the |
|
Closing, as the original issue is the expected behaviour for revision trees with conflicts. |
I'm experiencing another issue similar to #961 where a document's revisions grow very large (several hundred revisions in the _raw output).
Short summary:
deleting a document locally and then recreating it before the replication has had a chance to pull a copy from sync_gateway causes revisions to grow without limit.
Steps to reproduce:
"revs_limit" : 3(my config.json: https://gist.github.com/joshblour/620a60cd658938a58e10)Note: this only happens if the device creates a copy of the document before the replication has had a chance to pull the existing one. If it waits for the initial replication to finish before making any updates, the rev count stays at 3.
This could be the correct behaviour but I would have expected there to be a conflict and the server version to win because of the higher revision number.
The text was updated successfully, but these errors were encountered: