1 GB Push replication with attachment fails

[ashvindersingh]

Edit the value of "kSizeofAttachment" to 1 GB in the script https://github.com/couchbaselabs/iOS-WorkerBee/blob/third_installment/Tests/Test13_PushReplicateWithAttachment.m and execute it.
Please configure the sync gateway to use in memory walrus database. The test displays the replication is complete but there is no document found on Sync Gateway

[snej]

More details please. Are you sure your test code is checking errors?

[lichenyang2]

Re-post with better formatting:
Here is the error printed out from the test case when the attachment size is 1G

Notification replicationChanged lastError:(Error Domain=CBLHTTP Code=400 "400 bad_request" UserInfo=0x906abc0 {NSURL=http://localhost:4985/db/DFA647F6-CE46-4D01-87EA-EBC754275C4C?new_edits=false, NSLocalizedFailureReason=bad_request, NSLocalizedDescription=400 bad_request})

I also added printf in sync_gateway code to get more details about the error:

23:40:18.221418 WARNING: ------------- Get to ErrorAsHTTPStatus err=400 MIME part #2 doesn't match any attachment-------- -- base.ErrorAsHTTPStatus() at error.go:42
23:40:18.221462 HTTP: #11: --> 400 MIME part #2 doesn't match any attachment (0.0 ms)
2014/06/17 23:40:43 go-couchbase: Tap feed from 172.23.96.65:11210 failed: 20000009 is too big (max 20000000)
2014/06/17 23:40:43 go-couchbase: TAP connection lost; reconnecting to bucket "bucket-1" in 1s

I tried it with attachment size of 20M. The result doc_size is 2000009, which reuslt in the following error regarding tap feed, but from the client side, there is no error. Should the client get error in this situation?

2014/06/17 23:53:53 go-couchbase: Tap feed from 172.23.96.62:11210 failed: 20000009 is too big (max 20000000)
2014/06/17 23:53:53 go-couchbase: TAP connection lost; reconnecting to bucket "bucket-1" in 1s

[tleyden]

@lichenyang2 thanks that's much easier on the eyes. Btw I deleted your previous post (and you can also edit posts)

[snej]

Li: You need to run this test with walrus. Your logs show you ran it with Couchbase Server, where the max attachment (or doc) size is 20MB. Please re-run with walrus.

[lichenyang2]

Doc with 1G attachment does fail with Walrus, with error in Walrus log as following. However, there is no error seen on Xcode console. Query on Walrus db shows that there is no document created.

23:30:15.069755 Bucket: Update("_sync:user:", 0, ...) --> CAS quit [40.38us]
23:30:15.069770 HTTP:  #042: GET /db/_local/74a6be149e13368ec518f2dedbd8d6d65606f597
23:30:15.069777 Bucket: Get("_sync:local:74a6be149e13368ec518f2dedbd8d6d65606f597") [942ns]
23:30:15.069796 HTTP: #042:     --> 404 missing  (0.0 ms)
23:30:15.070909 Bucket: Update("_sync:user:", 0, ...) --> CAS quit [34.824us]
23:30:15.070920 HTTP:  #043: POST /db/_revs_diff
23:30:15.071109 Bucket: Get("13468225-4CBF-4F1A-823C-6A4BD8642E43") [1.094us]
23:30:15.071167 HTTP+: #043:     --> 200   (0.0 ms)
23:30:15.072730 Bucket: Update("_sync:user:", 0, ...) --> CAS quit [58.288us]
23:30:15.072741 HTTP:  #044: PUT /db/13468225-4CBF-4F1A-823C-6A4BD8642E43?new_edits=false
23:30:19.032965 HTTP: #044:     --> 400 MIME part #2 doesn't match any attachment  (0.0 ms)

I did binary search for the size of document that would fail the same way. The result is that size of 537000000 would fail, but size of 536000000 is ok.

[snej]

I don't understand why this is failing or why it would start to fail at a magic size around 537MB; I'm guessing it's possibly a bug in the MIME parsing code in Go.

Regardless, since we don't currently support storing attachments over 20MB, this isn't important to investigate. We can save it for the future after we add large-attachment support.

[snej]

Pasin says he found that pushing a doc with a huge attachment (too big to fit in memory) would fail (or crash?) when running on a real iOS device. From the backtrace it looks as though the attachment gets loaded into RAM and expanded into base64 — that shouldn't be happening, its metadata should have a "follows" key instead of "data" and the data should be sent as a separate multipart body.

[pasin]

I think I have a little bit old code that doesn't have 503f000 commit. Let me retest it.

[pasin]

Still has the same problem. The attachment is always expanded. I tried to follow the codes and found that the following block returns stub attachment dictionary even though the follow attribute is YES but changing that part of code alone doesn't work (leading to a new issue that doc doesn't get store).

https://github.com/couchbase/couchbase-lite-ios/blob/master/Source/CBLDatabase%2BAttachments.m#L345

[snej]

Yes, I think this has been broken for at least a few months. The attachment related code has gone through changes twice lately — once for ForestDB and again to support streaming. I think I broke this in one of those.