[swx] Bug in LoadManager & solution

[Ben Lagoutte]

Hi Aral, and everyone on the list,

I've been running into this issue with a recent project, and looking at 
the mailing list archives some other people have had that problem too 
(Bennie Jolink's post on the 29/12/07 for instance). I think I posted 
the issue on the list a while back too but never got anywhere.

There's a problem with the way the swx request calls are handled on the 
actionscript side.

The problem happens when multiple swx calls are made in a very close 
period of time by different elements. The request seems to get stuck 
indefinitely and so do all subsequent calls to swx.

A few people have suggested using cancelAllLoads() on the LoadManager as 
a solution. Although it does do the job of clearing existing calls and 
work in some cases it's really not a "solution". You can easily picture 
cases where one component should not use cancelAllLoads because another 
component is likely making an independent call of its own.
Other people also suggested doing swx calls one after another by calling 
swx in sequence in result callback handlers, but that's assuming call 
are tied together in some kind of logical sequence.

So I've spent a bit of time going through the swx AS API and I think 
I've found where the problem is.

Within the LoadManager when calls are generated an id is generated for 
the movieclip holder based on the queue length, then the item is added 
to the queue and the queue start being processed. At that stage the 
queue is right away emptied of its first element.

I think what's been happening is that one call would be made and a 
holder would be created based on the id 0 (empty length = 0), then be 
added to the queue (queue length = 1) and the queue would right away 
start being processed, with its first element shifted right away (queue 
becomes empty again, length = 0 by the time the call() method returns). 
Then separately a second swx call would then happen before the first one 
completes, and again a movieclip holder would be created based on the id 
0 again (because the queue is already empty, even though one request is 
still pending).

While the LoadManager wait for "holder0", an new "holder0" is created, 
overwriting (I think, I'm not sure how flash handles references but it 
seems to get lost) the previous one . Either way, the LoadManager then 
waits infinitely for the first "holder0" to trigger an event that will 
never occur.

I've made an updated version of the LoadManager that generates ids based 
on an increment rather than the queue length and that seems bulletproof 
now on that error with our project, hopefully that will help other 
peoples too.

I've attached the updated version to this email, maybe that can be 
integrated to the next version?

Additionally, I think (you tell me if there's a potential issue I 
haven't thought about with that) in the loadNextExternalAsset function, 
a slight optimisation would be to respond to the LOADED_BUT_NOT_READY 
event rather than LOAD. I don't think the queue manager needs to wait 
for the response movie to be fully ready to start processing the next 
item in the queue.

Hope that's helpful.

Ben


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/swx_osflash.org/attachments/20080603/de97c2fe/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: LoadManager.as
Url: http://osflash.org/pipermail/swx_osflash.org/attachments/20080603/de97c2fe/attachment.pl