[swx] Bug in LoadManager & solution

[Jake Ketcheson]

Yep, works awesome!
Thanks again.

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