[swx] Bug in LoadManager & solution

[holger arndt]

you're the man ;-)
thanks for taking care of this.

Cheers,
Holger

Am 03.06.2008 um 01:35 schrieb 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/3ea0d0d8/attachment.html