Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of markphip@gmail.com designates
 209.85.214.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8761g3lwe9.fsf@ntlworld.com>
References: 
 <CALL-kDfu4xbz3SNiwxwP73N707Wj_8GZZymPsEn-roKqJ7V2pg@mail.gmail.com>
	<87sijeda7h.fsf@ntlworld.com>
	<CALL-kDcfQgN-66uMfmXJJr0K6=u+prWE8TOXdY_i75RwGszEeg@mail.gmail.com>
	<5427CDF0.2010205@wandisco.com>
	<87k34mrbii.fsf@ntlworld.com>
	<CALL-kDf96EgvD8NmbUZQhapg5yqZ3_u19jpi-G=uHPrRc7CX6w@mail.gmail.com>
	<5429A12F.9080306@wandisco.com>
	<CALL-kDdv+O8XtrGRiWZ4-T4bmPtG1LZ+KbpYjgeje3zndYgn_Q@mail.gmail.com>
	<542B068F.4030906@gmx.de>
	<87a95gkqux.fsf_-_@ntlworld.com>
	<542BFC6D.7000204@gmail.com>
	<8761g3lwe9.fsf@ntlworld.com>
Date: Wed, 1 Oct 2014 10:36:48 -0400
Message-ID: 
 <CAHFaGCo7BFp+5aWmoBtJBWjjGMoi2pNsLY6eb9UTOcNwuW=xcw@mail.gmail.com>
Subject: Re: [serf-dev] serf errors on responses bigger than 4GB
From: Mark Phippard <markphip@gmail.com>
To: Philip Martin <philip.martin@wandisco.com>
Cc: "C. Michael Pilato" <cmpilato@gmail.com>, serf-dev@googlegroups.com,
	Andreas Stieger <andreas.stieger@gmx.de>,
 Subversion Development <dev@subversion.apache.org>
Content-Type: multipart/alternative; boundary=047d7b2e44c211230705045d6ece

--047d7b2e44c211230705045d6ece
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 1, 2014 at 10:03 AM, Philip Martin <philip.martin@wandisco.com>
wrote:

> "C. Michael Pilato" <cmpilato@gmail.com> writes:
>
> > The log message for r2419 mentions "files" larger than 4Gb, and leads me
> > to believe that this problem only affects GETs.  But here, Philip avoids
> > the term "files" and talks about the "compressed size".  Does the bug
> > fixed in r2419 manifest on any response > 4GB, such as a bulk-mode
> > REPORT carrying a whole Subversion tree that's larger than 4GB?
>
> I can trigger the decompression error on a 5GB REPORT by setting
> http-bulk-updates=yes on the client side.
>
>
This does not really answer the question.

Was your REPORT 5GB because it had a single file > 4GB or because it had
tens of thousands of small files?  Mike's question is about the latter.

Does Serf only fail when decompressing a single large file, or also if the
entire REPORT response happens to be > 4 GB?  The latter probably would be
a much more common problem to run into if it can happen.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

--047d7b2e44c211230705045d6ece
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Oct 1, 2014 at 10:03 AM, Philip Martin <span dir=
=3D"ltr">&lt;<a href=3D"mailto:philip.martin@wandisco.com" target=3D"_blank=
">philip.martin@wandisco.com</a>&gt;</span> wrote:<br><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">&quot;C. Michael Pilato&quot; &lt;<a href=3D"mailto:cmpilato@gmail.co=
m">cmpilato@gmail.com</a>&gt; writes:<br>
<br>
&gt; The log message for r2419 mentions &quot;files&quot; larger than 4Gb, =
and leads me<br>
&gt; to believe that this problem only affects GETs.=C2=A0 But here, Philip=
 avoids<br>
&gt; the term &quot;files&quot; and talks about the &quot;compressed size&q=
uot;.=C2=A0 Does the bug<br>
&gt; fixed in r2419 manifest on any response &gt; 4GB, such as a bulk-mode<=
br>
&gt; REPORT carrying a whole Subversion tree that&#39;s larger than 4GB?<br=
>
<br>
</span>I can trigger the decompression error on a 5GB REPORT by setting<br>
http-bulk-updates=3Dyes on the client side.<br><br></blockquote><div><br></=
div><div>This does not really answer the question.</div><div><br></div><div=
>Was your REPORT 5GB because it had a single file &gt; 4GB or because it ha=
d tens of thousands of small files?=C2=A0 Mike&#39;s question is about the =
latter.</div><div><br></div><div>Does Serf only fail when decompressing a s=
ingle large file, or also if the entire REPORT response happens to be &gt; =
4 GB?=C2=A0 The latter probably would be a much more common problem to run =
into if it can happen.=C2=A0</div></div><br>-- <br>Thanks<br><br>Mark Phipp=
ard<br><a href=3D"http://markphip.blogspot.com/">http://markphip.blogspot.c=
om/</a>
</div></div>

--047d7b2e44c211230705045d6ece--