Closed GoogleCodeExporter closed 8 years ago
Hi Andy.
First of all, if a core functionality is that broken, it should really be fixed.
That said, there are unit tests for this on the test suite. I've also just did
a quick test class (attached here), that
seems to work fine, for a variety of loading types including swfs. This is a
small flex class. Just fire it up, click
the start, watch the connection being opened on the browser. Click stop, the
connection is closed.
Locally, I see all of the expected behavior, which is for the connections to be
closed. On a Safari and Firefox, I
can see the browser closing the connection.
A few pointers to help on debugging.
1. To understand better what you are describing as a bug:
a) It helps to have a bare case minimum test. No buttons or pages, just a
bulkloader starting and then being
paused (I've attached this to this issue report).
b) How are you concluding it does not work? Are you spoofing the requests on
the browser? By which means?
Events might still fire, depending on how you've set it up.
Now you need to decouple this from your application logic, since it might not
be related to bulkloader at all.
Also, note that while what you are doing is possible, and in theory should
work, BulkLoader has functionality
design to help you in these cases. You could:
1. create the BulkLoader instance
2. Add all the swfs you might need
3. Load them with numConnections =1
4. If something on your application happens and you desire to change prioritys
on the fly, you can say:
bulkLoader.loadNow("some-key-or-url");
I'll keep this ticket open, in case more infor surfaces and it is clear that it
really is a bug.
Cheers
Arthur Debert
Original comment by debert
on 24 Feb 2009 at 8:57
Attachments:
Hi Arthur,
Thanks for the speedy reply! It was my mistake - You were right, but I did
notice
something else:
I ran a simple test with a basic start and stop button and a single download.
the
start button calls "resumeAll" and adds the progress and complete listeners on
the
individual item. The stop button calls "pauseAll" and removes the listeners.
When I
hit the start, it began the download. When I hit the stop, it paused.
Then, when I hit start again, the download started from 0% again. I am using
Windows
Task Manager to track my Flash memory usage and I noticed that even though the
download started at the beginning again (according to the ProgressEvent
listener),
the memory usage did not decrease. In other words, the partial download is still
sitting in memory. Is this correct? the API docs for "resumeAll" say that
"resumed
items will be able to use partialy downloaded content." In what scenarios is
this true?
Thanks again for this class,
Andy
Original comment by andy.wat...@gtempaccount.com
on 27 Feb 2009 at 2:56
Hi Andy.
Good to know you got the pause resume working.
There are a few things to keep in mind with pause/resume. Honestly, it's almost
a poetic license.
There is really no such thing as pause and resume itself. The player kills the
request. What is suppouse to
happend is that the bowser should be able to resume the request, but it depends
on the browser itself. I
cann't really remember the fine details, but support for actual resuming was
inconsistent amongst browsers
and all.
All that to say that bulkloader does as much as the runtime allows, but your
milage may vary ;)
Regarding memory consumption...
I am always a bit paranoid about memory leaks in BL. I've tried to make sure
none occur, but honestly, pause
resume might be a corner case. That said, can you be positive it is leaking
memory? Running it on the profiles
**and** forcing garbage collection to run is the one way to check. If the
memory is being used but the gc
hasn't reclaimed it yet, it will linger on.
If you can confirm that or give more pointers I'll take a better look.
Cheers
Arthur Debert
Original comment by debert
on 27 Feb 2009 at 3:11
Original issue reported on code.google.com by
andy.wat...@gtempaccount.com
on 24 Feb 2009 at 8:22Attachments: