actionscript 3: Loaders silently fail on error prone connections

Our Flash app has to load 50 开发者_JAVA百科or so files from a remote destination. Under normal network conditions, this is no problem. However some of our users started to report that the application "stopped working" during the loading phase.

After some tests where we decreased the network quality to a point where 1 out of 3 packets were dropped in bursts, we managed to reproduce the error reports. Looking at firebug, it appears as if a few of the files (1 to 3 out of the 50) begin loading but never complete. No errors are raised in ActionScript and there is no apparent pattern in which files fail to complete.

Has anybody run into situation before and found a cause and or fix to deal with these situations ?

It's not too hard to write something that manually verifies if loaders stop loading and restart the loading process, but I was wondering if we're simply not listening to the right error events (right now we listen to progress, complete, and IOErrors) or if there are other solutions ?

Cheers Mark

How are you handling doing all of this loading? Are you just using Loaders (or subclasses of, like URLLoader) or are you using a library that will handle all of these for you?

Greensock's LoaderMax and BulkLoader are what I use when I have mass loading to do. I only recently started using LoaderMax over BulkLoader because of some nice features it has.

Ok a long overdue follow up from a different account.

Thanks for all your suggestions. We've got a workaround which involves rescheduling loads when the server fails to respond in time or the client no longer receives bytes for X amount of time. At the worst this will mean users will have to wait a bit longer.

The cause of the requests silently failing is still a mystery though.

@Danyal - good suggestion, I suspect this isn't the case as our Loaders are managed, but I'll have to check to be 100% sure.

One things you might want to take a look into is if you're making all of these requests all at once they loading might timeout and cause your files not to load. Servers often have limitations on how many concurrent requests it can serve up.

Therefore, it's good practice to manage your loading so that you load items one after another rather than start them all and wait until they all finish.

Have you checked that you are maintaining references to your loaders? If you are defining loaders as local variables with weak listeners there is the chance that they could be garbage collected before the loading process completes, and the failure will be silent.

raix, while strictly speaking is not a loading library, has an example on Loading multiple XML documents and outputting a typed value which including handling errors and timeouts.

The code below loads an XML document and falls back to a static version after 10 seconds (though it could easily chain another XML load between the two):

Observable.xml(new URLRequest(xmlDocumentURL))
    .timeout(10000, Observable.returnValue(defaultProductCategories))
    .subscribe(function(xml : XML) : void
    {
        trace("Either way, we have an XML document");
    });

I have an adobe Air mobile application that loads from an URL which is served up by a PHP file. My loader would silently fail and not return any data (using generic loader OR Greensock). So I did what you ended up doing by just checking for a silent fail and simply retrying. This worked, but I realized how ridiculous this was, plus the situation got worse on the mobile device as opposed to the debugging simulator.

Here is what I found as a fix or has at least greatly alleviated the amount of failures:

Old way: In my PHP file I would run a database query, package up the data formatted into XML, convert any binary to Base64 and then I would send the header information followed by echoing out my completed XML.

New way: What I did was right away send my header information ASAP, then do a PHP flush(); followed by my database query, xml packaging and encoding, then echo out the completed XML.

So far seems to have fixed it, I still check for failures, but there are MANY less.

My server is also plenty capable of handling these requests, and I am not packaging that big of an XML to even consider it needing a preliminary flush. Plus when I load that URL from a web browser, everything works fine, always. Which is why I never considered that to be an issue.

I believe the reason it is fixed now is because by sending the headers ASAP the application knows that its request was acknowledged and data will be coming. It would seem that http requests are very short-lived for their timeouts (at least in AS3), causing the mass amount of failures.