3

All,

I'm working on an Flash/AS3 project that makes numerous URLLoader.load() requests.

Should I queue them so that there's only a single open request at any time? Or, is it a good practice to allow multiple open requests?

Is there a limit to the number of open requests?

(I'm assuming I can manage the implications in the UI).

I've run tests locally with up to 5 simultaneous requests, and it works just fine. But I need to make sure the application will work in the field, for users with older PCs, older browsers, browsers with multiple open tabs, etc.

Many thanks in advance for any advice and insight!

mattstuehler
  • 9,040
  • 18
  • 78
  • 108
  • 1
    I've found that using multiple at a time speeds things up, but if my UI is doing anything while loading, the more active loaders there are the more sluggish my UI gets. I'm assuming it's just IO usage limiting FPS... – jpea Mar 16 '11 at 15:18

3 Answers3

3

I ran into this problem ages ago when I was trying to load a ton of images. They were all local, so I just queued them up with the Loader. Queue hours debugging why images were null :S

I'm not sure if the limit is mentionned anywhere, but I found (if memory serves) around 30 was giving me problems. After that and I think it would reuse old connections: so if you have 100 load() calls, only the last 30 or so would be loaded.

Normally I queue up about 10 at a time, then load in the rest as they get completed. There's no real problem with multiple connections - though they will start to take up CPU power etc.

If you want to just ignore this, check out something like BulkLoader: http://code.google.com/p/bulk-loader/ which was created for this

divillysausages
  • 7,883
  • 3
  • 25
  • 39
  • 1
    Another thing to watch out for is Loaders and URLLoaders going out of scope. Be sure to keep references to them until one of their complete or error events occurs, especially if you use weak references for the listeners. I've noticed that if they go out of scope after calling load, sometimes the load will sneak in a complete event before the garbage collector gets to it, making you think everything is ok, but most of the time nothing at all happens after calling load -- neither errors nor events are dispatched -- when the loader goes out of scope. – Triynko Sep 06 '12 at 21:37
2

I don't know if there is any hard limit on this, but 5 simultaneous requests sounds quite reasonable. I know that most browsers use like 6 simultaneous connections, and probably that is the limit for Flash too.

I would use something like 5 loaders, and queue all loading transactions that go beyond that.

Malyngo
  • 863
  • 7
  • 18
0

This question was long ago. I came here from Google but thank you for the answers.

Things might have changed. I just test reusing URLLoader.load on Flex 4.6 and AS 3.

There's a tricky and undocumented limit here. The loader can be reused but only the last request got issued in once of callback.

ex.

timer:Timer = new Timer(5000);
timer.addEventListener(TimerEvent.TIMER, timerHandle);
timer.start();
var loader:URLLoader = new URLLoader(); // and need to add listeners for response

function timerHandle(e:TimerEvent):void {
    loader.load(certainURLRequest);
}

this works well. But the way below doesn't.

function timerHandle(e:TimerEvent):void {
    loader.load(firstURLRequest); // this request didn't get issued
    loader.load(secondURLRequest); // this request got sent
}

I dont' know the internals. This might relate to the single-thread EventLoop way of ActionScript, where the request will be processed after returning from the call back and the last one overwrites the previous. It is all my guess out.

Hope this helps the followers coming here.

Edward Liang
  • 100
  • 1
  • 8