weixin_39966644
weixin_39966644
2020-12-29 11:48

Revision pruning isn't effective when history includes conflicts (even when tombstoned)

Issue originally raised as followup to https://github.com/couchbase/couchbase-lite-ios/issues/509. Crux of the issue is that tombstoned conflict branches are preserved during revision pruning, so documents with many (resolved) conflicts result in very large document bodies.

该提问来源于开源项目:couchbase/sync_gateway

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

10条回答

  • weixin_39966644 weixin_39966644 4月前

    Notes from the related email thread:

    The issues seem rooted in difficulty pruning revisions causing documents to balloon in size (< 25KB of data in a 14MB+ doc even with no conflicts and a MaxRevLimit set to 20). We’ve gone through a week of troubleshooting with lots learned, but no clear resolution in sight.

    点赞 评论 复制链接分享
  • weixin_39966644 weixin_39966644 4月前

    Reviewing potential solutions with Chris and Jens. The main concern is ensuring pruning is consistent across both SG and clients. If not, clients will be attempting to recreate previously pruned revisions on subsequent updates to the doc.

    点赞 评论 复制链接分享
  • weixin_39593519 weixin_39593519 4月前

    Have there been any updates to this one? We have a few documents that have ballooned in size and might be causing some performance problems.

    点赞 评论 复制链接分享
  • weixin_39593519 weixin_39593519 4月前

    Dumb question, but if you manually deleted a portion of a document's history, would that suffice? Or is there other housekeeping that would be thrown off by that?

    点赞 评论 复制链接分享
  • weixin_39966644 weixin_39966644 4月前

    I'm still working on this fix - expect to have it ready in a feature branch by the end of the year, and included in the 1.1.0 release. Manually deleting a portion of a document's history isn't recommended - it's likely to cause other replication issues.

    点赞 评论 复制链接分享
  • weixin_39593519 weixin_39593519 4月前

    Ah, I see -

    So I tried to resolve some of these conflicts manually by using the REST API with the conflicts=true&revs=true&revs_info=true set, but the request returned no conflict info for the document in question, despite there being some hundreds of conflicts stored remotely. revs_info also returned no information for the doc in question, so I'm pretty much at a loss for how to decrease the doc size.

    I'm wondering if there isn't some quick workaround for this in the meanwhile, as I suspect that at least one document became large enough to actually choke the sync gateway at one point.

    点赞 评论 复制链接分享
  • weixin_39593519 weixin_39593519 4月前

    Hey - any update on a potential workaround for this?

    点赞 评论 复制链接分享
  • weixin_39641236 weixin_39641236 4月前

    Hey : I'd like to see why SG reports no conflicts. Could I see a JSON dump of the doc as stored in the SG bucket, including the _sync property? (Actually the _sync property is all I need to see, in case the doc body is sensitive.) Thanks!

    点赞 评论 复制链接分享
  • weixin_39641236 weixin_39641236 4月前

    : Never mind! After re-familiarizing myself with the issue I understand why it's going on. The patch I just submitted for review should fix it.

    点赞 评论 复制链接分享
  • weixin_39593519 weixin_39593519 4月前

    Thanks so much ! I'll look into the patch as soon as I can and let you know if it doesn't clear it up.

    点赞 评论 复制链接分享

相关推荐