[swx] Bug in LoadManager & solution

[Nederflash (Folkert Hielema)]

Great man,

Thanks a lot on behave of every SWX loving man/women out here and there.

Folkert Hielema @ nederflash.nl

Ben Lagoutte wrote:
> 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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> swx mailing list
> swx at osflash.org
> http://osflash.org/mailman/listinfo/swx_osflash.org
> 
> 
> ------------------------------------------------------------------------
> 
> 
> No virus found in this incoming message.
> Checked by AVG. 
> Version: 8.0.100 / Virus Database: 269.24.5/1479 - Release Date: 6/2/2008 7:02 PM