[swx] Bug in LoadManager & solution

[Rob Slegtenhorst]

Great job! J fixed an issue I was working on straight away.

 

From: swx-bounces at osflash.org [mailto:swx-bounces at osflash.org] On Behalf Of
Ben Lagoutte
Sent: dinsdag 3 juni 2008 1:35
To: SWX Mailing List
Subject: [swx] Bug in LoadManager & solution

 

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/73ed286b/attachment.html