[swx] Bug in LoadManager & solution
jake at fiveht.com
Mon Jun 2 16:46:39 PDT 2008
You're a god man, I've been going crazy with a site occasionally not
loading data at random times on different computer setups and this
sounds like exactly what the doctor ordered.
I'm going to do a test with it tomorrow and let you know the results. If
it works I owe you an internet or two.
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
> 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.
> swx mailing list
> swx at osflash.org
More information about the swx