[swx] Bug in LoadManager & solution

[Ben Lagoutte]

Looks like a fair few people were running into the same problem.

Glad I could be of some help.

Ben

Jake Ketcheson wrote:
> 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
>>     
>
> _______________________________________________
> swx mailing list
> swx at osflash.org
> http://osflash.org/mailman/listinfo/swx_osflash.org
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/swx_osflash.org/attachments/20080604/c70ffd94/attachment.html