[
https://issues.apache.org/jira/browse/COUCHDB-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266663#comment-14266663
]
Alexander Shorin commented on COUCHDB-2535:
-------------------------------------------
[~rnewson] Negative result is also the result: if replication cannot store
document due to some constraints on the target side this isn't a fatal error,
but constraints of the target side. Currently, for replication,
validate_doc_update functions plays filter role on target side disallowing
storing unwanted data. Trivial example: how to clean database from all deleted
documents? Create another db with validate_doc_update which rejects docs with
_deleted:true property and run replication. Swap databases when it's done.
>From that point, max_document_size, plays the same filter role on the target
>side limiting the data which may be stored. Just not by some JSON data, but by
>his binary size. Assuming that, hitting that limit shouldn't cause any crush,
>but force target to return 413 and let replicator respect such response.
> Crash when replicating doc that exceeds max_document_size
> ---------------------------------------------------------
>
> Key: COUCHDB-2535
> URL: https://issues.apache.org/jira/browse/COUCHDB-2535
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Replication
> Affects Versions: 1.5.1
> Reporter: Rami Alia
>
> DB SOURCE has a max_document_size of 400MB, DB TARGET has a max_document_size
> of 40MB. Attempt to replicate a doc greater than 40MB from SOURCE to TARGET.
> Observed result:
> SOURCE replicator crashes followed by SOURCE couchdb crashing
> Expected result:
> SOURCE/TARGET handle this as gracefully as a validation fail and not crash
> replication or couchdb
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
