Received: by 10.90.59.3 with SMTP id h3mr579544aga.11.1290648722249;
        Wed, 24 Nov 2010 17:32:02 -0800 (PST)
X-BeenThere: gdata-objectivec-client@googlegroups.com
Received: by 10.90.17.22 with SMTP id 22ls379526agq.2.p; Wed, 24 Nov 2010
 17:32:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.91.42.20 with SMTP id u20mr112515agj.10.1290648721163; Wed, 24
 Nov 2010 17:32:01 -0800 (PST)
Received: by i32g2000pri.googlegroups.com with HTTP; Wed, 24 Nov 2010 17:32:01
 -0800 (PST)
Date: Wed, 24 Nov 2010 17:32:01 -0800 (PST)
In-Reply-To: <c2b2ce6e-1a5a-46d2-9847-bcc984e8ab38@35g2000prb.googlegroups.com>
X-IP: 75.172.87.33
References: <5e39f603-34ca-40fd-b324-9af72f7500c1@n32g2000pre.googlegroups.com>
 <2881f9c4-8f9a-426e-8db2-7985f6af5a21@j29g2000prf.googlegroups.com>
 <AANLkTimDBm+0Z6HszJN=fWPWxcunU0e6Tc7xH=8BUDO=@mail.gmail.com>
 <AANLkTim8ya+FFwG_NhQ6ZmXSYMMDqafgyBz-GbpwWXgV@mail.gmail.com>
 <fde4ef6c-f135-445f-b07a-567944e92b9d@m20g2000prc.googlegroups.com>
 <AANLkTikSngqj5NZgRBk0d5g6iqwxvZ1huGZxa3PCix9D@mail.gmail.com>
 <7763e663-cdbc-407c-abf5-3e1efb1ba1ef@x14g2000prb.googlegroups.com> <c2b2ce6e-1a5a-46d2-9847-bcc984e8ab38@35g2000prb.googlegroups.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.12) Gecko/20101026 AlexaToolbar/alxf-1.54 Firefox/3.6.12,gzip(gfe)
Message-ID: <1ee371d8-1b8a-4d34-a464-aa07ee21ea00@i32g2000pri.googlegroups.com>
Subject: Re: Resumable uploads stopped working through Obj-C API (503 error)?
From: "Christoph Z." <christop...@gmail.com>
To: Google Data APIs Objective-C Client Library Discussion <gdata-objectivec-client@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Greg - are you sure the minimum supported upload chunk size is 256 K?

I took the latest top-of-trunk sources to experiment further. I've
modified uploadFileAtPath: in the DocsSample by adding :

[service setServiceUploadChunkSize:1024*1024];

The upload of large PDF files continues to fail. In fact, it fails
with chunks as big as 5 MB. Note that such limit is way too big for 3G
mobile networks. The reason why we've originally set chunk size to 256
K is because from our fairly extensive experiments, it offered the
optimal upload reliability over 3G networks. 1 MB would be OK, but
larger chunks will definitely cause a problem.

Mainly I want to understand what is the desired server behavior in
this case and understand if the current behavior is considered a bug
which will be address soon or is by design (and thus requires our
application to be updated immediately).

Again - thank you for looking into it - I really appreciate your help.

-Chistoph

On Nov 24, 3:52=A0pm, "Christoph Z." <christop...@gmail.com> wrote:
> By the way - to repro it using the DocsSample app, I've added the line
> below to uploadFileAtPath:
>
> [service setServiceUploadChunkSize:256*1024];
>
> On Nov 24, 3:50=A0pm, "Christoph Z." <christop...@gmail.com> wrote:
>
> > Hi Greg,
>
> > It looks like resumable uploads are broken for chunks smaller or
> > *equal* to 256 K. The app that we have in production uses 256 K and
> > stopped working yesterday. By the way, the top-of-trunk still uses 256
> > K on older iphones (which won't work in this case) :
>
> > if (![GDataHTTPFetcher doesSupportSentDataCallback]) {
> > =A0 =A0 =A0 // for iPhone 2, we need a small upload chunk size so there
> > =A0 =A0 =A0 // are frequent intrachunk callbacks for progress monitorin=
g
> > =A0 =A0 =A0 //
> > =A0 =A0 =A0 // Picasa Web Albums has a minimum 256K chunk size when
> > uploading photos
> > =A0 =A0 =A0 val =3D 256*1024;
> > =A0 =A0 } else {
> > =A0 =A0 =A0 val =3D 1024*1024;
> > =A0 =A0 }
>
> > Upgrading to top-of-trunk sources is trivial for development and our
> > next update, but the recent server change is a breaking change that
> > affects our existing customers. Updating an app in the AppStore is a
> > 7-10 days process. Given Xmas iTunes Connect shutdown between 12/24
> > and EOY, we might not even be able to get an update approved before
> > January. A broken functionality means significant loss in revenue. As
> > you can imagine - this is a huge concern to us.
>
> > When you say that server team is aware of the issues with chunks
> > smaller than 256 K - do you mean we can expect a fix shortly or it
> > won't ever be fixed? I do not intend to use chunks smaller than 256 K.
> > It's just that as of today, 256 K doesn't work anymore in v1.10.0 and
> > that's what we've been shipping for months.
>
> > Thanks,
> > Christoph
>
> > On Nov 24, 3:34=A0pm, Greg Robbins <grobb...@google.com> wrote:
>
> > > Please use the top-of-trunk library, not the 1.10 release. It has
> > > appropriate chunk size defaults, as well as http log requests/respons=
es that
> > > are much easier to copy and paste.
>
> > > The server team is aware of issues with chunks smaller than 256K and =
apps
> > > should not use chunks that small.
>
> > > Using the DocsSample application, I was able to upload the pdf file f=
rom the