Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Installer errors in last week
From: Justin Mclean <justin@classsoftware.com>
In-Reply-To: <D0201927.2CAD9%aharui@adobe.com>
Date: Mon, 25 Aug 2014 16:29:30 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <60FC00A9-CB28-4FE7-9F31-4FE47DF12E50@classsoftware.com>
References: <E98F0794-FDD9-4A8E-B69A-3DAE92729025@me.com>
 <D0201927.2CAD9%aharui@adobe.com>
To: dev@flex.apache.org

Hi,

> The download failure rate gets skewed when the MD5's become out of =
date
> because folks try again right away, maybe even more than once and get =
the
> same failure.
About 1/3rd of people try again, 2/3rd give up I would assume (pageview =
vs unique pageview).

> The MD5Checker seems to work, but the CI server keeps hanging saving =
the
> artifacts of the flex-sdk-release build and then MD5Checker doesn't =
get to
> run.
Can we make this more reliable by have it use a pre built SDK?

> But really, the theme remains that download reliability is poor.
Downloading from multiple locations probably makes the issue worse, =
having multiple points of failure, but it seems odd the majority of MD5 =
failures are for our SDK - except when the player changes.

>  I'm starting to wonder if there is a bug in URLLoader that makes it =
less
> forgiving in large downloads.
That also seems likely to me.

>  Maybe we need to implement some other, more reliable download =
mechanism. =20
Chunking and check sums for each chunk and re-sended any that fail? =
Although seems like a lot of effort to go to.

Thanks,
Justin=