Take the 2-minute tour ×

Our Flash app has to load 50 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

share|improve this question
I've seen something similar to what you describe in a situation where lot's of Loader objects' load() method is executed at the same time... perhaps try sequencing your loads if you aren't already? –  heavilyinvolved Jul 30 '10 at 3:38
Thanks. I will definitely look into that. Right now we're sending out all the requests as soon as the client code provides them. Effectively this means we're sending about 40 out of 50 requests out at the same time. Do you happen to know why sending out many request could result in these problems ? –  Mark Jul 30 '10 at 3:53
make sure your registering these events on loader's loaderInfo object. And try listening to httpStatus event as well which might tell you what went wrong i.e. TimeOut or other server responses. –  bhups Jul 30 '10 at 4:08
Yeah, thanks for mentioning that. We're already listening to the loaderinfo. The HTTPStatus is something to add as well although if Firebug is any indication that may not help much. Firebug just gives a 200 on those resources. Thanks for all the suggestions. I'll let you know how it turned out. –  Mark Jul 30 '10 at 4:32

6 Answers 6

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.

share|improve this answer
We're using Loaders and URLLoaders depending on the asset type. It's all coming from an inhouse library. Thanks for the suggestion, I'll have a look at the packages you mentioned. –  Mark Jul 30 '10 at 3:55

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.

share|improve this answer

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.

share|improve this answer
Maybe. However our server is not the bottleneck. Moreover, loading files one by one has been tried and lead to unacceptable load times. The current approach loads much, much faster load times, but gives problems for people with less optimal connections. Surely there must be a happy middle ground. –  Mark Jul 30 '10 at 5:19
It's actually not a matter of your server being slow it's a matter of your server not allowing a large number of concurrent connections. While Flash waits for more connections to become available they are timing-out. A good example would be visiting a wallpaper download site and trying to download many wallpapers at the same time. Your downloads usually only run three at a time at most. –  Henry Tseng Aug 3 '10 at 1:51

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.

share|improve this answer

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");
share|improve this answer

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.

share|improve this answer

Your Answer


