Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Content-Type: multipart/signed;
 boundary="Apple-Mail=_6CEBD386-9A1D-4B20-AF05-CAE22A9D0C7B";
 protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
Subject: Re: Help with a replicator incompatibility/crash?
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <48AFCAF8-72E4-4D0C-80C2-C458F6F74677@apache.org>
Date: Thu, 30 Jan 2014 15:01:29 +0100
Cc: replication@couchdb.apache.org
Message-Id: <D743BE1D-94AF-40D5-AB2D-088EE293387D@apache.org>
References: <B1016239-79B8-45F8-A212-C6EFDC43A819@couchbase.com>
 <B12CA026-08AC-43AA-A66F-1DFEF164DC6D@apache.org>
 <48AFCAF8-72E4-4D0C-80C2-C458F6F74677@apache.org>
To: "dev@couchdb.apache.org Developers" <dev@couchdb.apache.org>

--Apple-Mail=_6CEBD386-9A1D-4B20-AF05-CAE22A9D0C7B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I commented with a summary on the ticket again: =
https://github.com/couchbase/sync_gateway/issues/248#issuecomment-33689652=


I talked this over with @rnewson. The scenario appears to be this:

```
[14:39:41]  <+rnewson>	 but for the replicator to know to fetch =
"_design/foo" the source must have said it in the changes feed.
[14:40:06]  <+rnewson>	 if the source says "_design/foo" was updated =
*and* 404's when you fetch it, I don't see how it's the replicators =
problem.
```

In CouchDB, the above scenario is still possible, but rather rare. In =
addition, CouchDB will retry this if it fails and unless you look at the =
docs, you are none the wiser that this has happened.

The solution here is two-fold:
1. CouchDB should add a clause to handle non-200 responses and print a =
sensible error message about violating replication protocol expectations =
(we really need a proper spec soon).
2. sync_gateway should not send a _changes feed line for documents that =
can result in a 404, and/or handle the fact that CouchDB (pre-fix) bails =
on that or (post-fix) returns a sensible error.


On 30 Jan 2014, at 14:47 , Adam Kocoloski <kocolosk@apache.org> wrote:

> Correct, the CouchDB replicator fails on a 404 there.  There are =
relatively few occasions where the replicator will skip data and run to =
completion -- explicit validate_doc_update rejections and MD5 mismatches =
on attachments are two that come to mind.
>=20
> We could / should have the discussion about whether the replicator =
should make progress in the event of other failure modes like this one.  =
I could make a case for it, but I worry that no one will pay attention =
to any warning message or metric that gets reported.
>=20
> Adam
>=20
> On Jan 30, 2014, at 8:19 AM, Jan Lehnardt <jan@apache.org> wrote:
>=20
>> I commented on the issue:
>>=20
>> It looks like we are not handling a 404 in the function below, =
especially thefun(200, Headers, StreamDataFun) -> bit (that=92s like 171 =
in couch_replicator_api_wrap).
>>=20
>> I=92m not too familiar with that code, maybe one of Adam, Bob, =
Filipe, Benoit could have a look?
>>=20
>> cc dev@
>>=20
>> open_doc_revs(#httpdb{} =3D HttpDb, Id, Revs, Options, Fun, Acc) ->
>>   Path =3D encode_doc_id(Id),
>>   QArgs =3D options_to_query_args(
>>       HttpDb, Path, [revs, {open_revs, Revs} | Options]),
>>   Self =3D self(),
>>   Streamer =3D spawn_link(fun() ->
>>           send_req(
>>               HttpDb,
>>               [{path, Path}, {qs, QArgs},
>>                   {ibrowse_options, [{stream_to, {self(), once}}]},
>>                   {headers, [{"Accept", "multipart/mixed"}]}],
>>               fun(200, Headers, StreamDataFun) ->
>>                   remote_open_doc_revs_streamer_start(Self),
>>                   {<<"--">>, _, _} =3D =
couch_httpd:parse_multipart_request(
>>                       get_value("Content-Type", Headers),
>>                       StreamDataFun,
>>                       fun mp_parse_mixed/1)
>>               end),
>>           unlink(Self)
>>       end),
>>   receive
>>   {started_open_doc_revs, Ref} ->
>>       receive_docs_loop(Streamer, Fun, Id, Revs, Ref, Acc)
>>   end;
>>=20
>> On 29 Jan 2014, at 16:35 , Jens Alfke <jens@couchbase.com> wrote:
>>=20
>>> A developer has reported a CouchDB 1.3 exception/crash replicating =
with the Couchbase Sync Gateway. They've attached the Erlang crash =
report, but those are about as readable to me as ancient Aramaic, or the =
logos* of black-metal bands :(
>>>=20
>>> 	=
https://github.com/couchbase/sync_gateway/issues/248#issuecomment-33523814=

>>>=20
>>> Could someone who knows CouchDB take a look and give me a clue about =
what it might be taking exception [sic] to? In my experience, there are =
some areas where it gets very picky about parsing incoming data, for =
example the number of newlines at the end of a multipart body. If I had =
some idea what type of data it was reading when it barfed, that would =
help me figure this out...
>>>=20
>>> Thanks!
>>>=20
>>> =97Jens
>>>=20
>>> * viz.: =
http://www.rottentomatoes.com/quiz/the-most-unreadable-metal-band-logos/
>>=20
>=20


--Apple-Mail=_6CEBD386-9A1D-4B20-AF05-CAE22A9D0C7B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJS6ls5AAoJENnuAeR4Uq7kfM0QAJ6IERcIc675Gt0tiDfiuDo7
GFr1UUe3To6D1+zC1JNGUUS8TdkIEKt3EkxLokLNOeyF6kC+UoFp2R6weuepNC5e
v9WRsqPrGv3y96w6bobfcCBl1A8lEuaQOBGieOuyMAqEnZsGGyLnHEE+SSyJFNWU
eWbXLmnd+oC7/1jCq3Psu+5nHJeex7S0uT4PBT6SnFJcL3lJvqquHv00Su2ApciC
UMDqRtlEd89yiURJYFyyA8v3cKasEbiVYeaFTbwrUEZ/ZZXsfPsZl3MvkH/xZaVl
Nn2KMtQXl6tbh8dK17IAkTR9aBLWx/rA7XXK/bnbsCCEtPdrH5axxIR77SZLTzTX
iCbFX6yPo3BuuBvLZSm27BQ5cWC7JlJcQZBr9IMOE/q1MKToKexM+ritn9OQBSD/
f22js31axQIR+DTWg01nDlJyskeikPHf2BugDnmhTkEglx78hCPtcEWDrQ443iCU
lVsqwdg/oSU1KqKqbYKJZS8AlPb6sLJzPAsKBFeAlpdX/adt+YXwzwmQG5bBcSOl
MC0VQGAw3DLQgFdy+0FdQV/5pGwo9GuXSgIkfcpqd/QdMU++HxXEtfWTjenb+j6Q
Rp0dwGCcUJgeTk/BK9utPfohsQEgWwnTFgoNKlTfOBhdiWyr3CgNoLZHIwlhi5JQ
gh4FptuXyAIFZEYxtW+D
=nlP1
-----END PGP SIGNATURE-----

--Apple-Mail=_6CEBD386-9A1D-4B20-AF05-CAE22A9D0C7B--