Copy link to clipboard
Copied
This question was posted in response to the following article: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/Worker.html
Copy link to clipboard
Copied
I'm having a problem with the worker auto-unloading.
The scenario is the following:
- I have a background worker loaded using the Embed method (also tried with a loader).
- I load another SWF which has no relation to the worker, let's call it 'random.swf'
- I unloadAndStop the 'random.swf'
- I try to send a message to the background worker.
- The debugger tells me the MessageChannel is closed and the background worker has been unloaded.
Copy link to clipboard
Copied
There is an example project here
https://dl.dropbox.com/u/39362310/MP3Worker.zip
Copy link to clipboard
Copied
Thanks for reporting this, and especially for providing the example. We've filed a bug internally and it's being worked on. The current plan is to have it fixed by the next release.
Unfortunately the only workarounds are:
- Re-create the worker and restart it, or
- Don't use unloadAndStop on the root SWF
Copy link to clipboard
Copied
Also, one more "workaround" is to implement a timer (lets say 500 ms) in the "handleBGWorkerStateChange" handler, then, upon timer complete, call bgWorkerCommandChannel.send(["startCount", 100000000]);
This is very annoying bug.
Copy link to clipboard
Copied
Is there a memory limitation on the worker?
I have a worker based on code that worked fine inline. It downloads JSON data from a sync service via a POST. It currently works with the smaller sync blobs that I receive but one large one (that is already batched) hangs, the batch is about 2MB. I am using a URLLoader within the worker to get the data, the request is sent and I get a 200 response but then nothing, no other events fire, no error, nothing it just hangs until I have to force quit ADL.
So Im not sure what to try next.
Thanks for any help.
Copy link to clipboard
Copied
As a follow up to this:
I have tested running the exact same code via a direct call in the main thread and the worker thread. The main thread always works, the worker thread never works.
In tracing the bytes loaded of the URLLoader it essentially just stops in the middle of a transfer. It seems to happen in nearly the same place every time but sometimes goes a little further. The total bytes loaded ends up around 500k to 1.5MB over the course of usually 2 or 3 calls (data is loaded and processed and then repeated for another chunk of data). I tried everything I could think of, disabled cache, disabled cookies support, etc. Nothing works and no error is ever thrown.
I also made a release build to make sure that it wasnt a problem with the debugger in 4.7b2 but the same problem occurred.
So, it would appear that the thread has a memory ceiling of some sort but maybe I'm wrong.
Any insight would be great as Im banging my head against my desk at this point.
Thanks.
Copy link to clipboard
Copied
For anyone who may be experiencing the same or similar problem using URLLoader or HTTPService within a Worker, this is how I got around the problems described above.
I move the download portion of the code to the main thread. I then pass the data through the message channel to the worker so it can be processed. It is slightly slower but the worker doesn't blow up (oh and according to Scout it does blow up, in fact it just stops).
It is also more of a pain because you can't seem to pass a class that extends Event through the message channel, I always get a type coercion error, so I had to make objects to pass data across the divide and then recreate and dispatch an event on the other side so everything would work as normal.
Copy link to clipboard
Copied
Is that really the best we can do? I'm loading large amounts of data that I was OVERJOYED to be able to use workers for... and all it does is hang. I load on main thread fine, but of course UI is on hold till we get done. Did you ever find anything better than abandon the worker loading idea and load the data back on the main thread?
Copy link to clipboard
Copied
Jason,
Sorry it took so long to reply, but no, I was not able to find another solution. Im not sure if this has been fixed in the latest beta's as I havent had time to test.
Copy link to clipboard
Copied
Jason I tested it in 11.6 and wasnt solved yet.. also it seems to work in flash player 11.5 (not debug)
thanks!
Copy link to clipboard
Copied
Well I have come to the conclusions that workers are still too new to use. I gave up on the first attempt and decided to use the worker for another job.... handling our polling service calls and processing the data. These are not large at all, but I hoped offloading them to a worker, I could run them more frequently to keep our data more real-time. Well the results of that attempt ended with failure as well. The worker fires up... starts the timer and begins polling. It makes it through somewhere between 2 - 5 timer iterations before it hangs. Doesn't seem to be any "pattern" to when it stops... it just gets tired at some random point and quits . I guess these workers just aren't ready for prime time yet. For the record, we are using air 3.4, 11.4 & 11.5 tested, apache flex 4.9 .
Copy link to clipboard
Copied
I'm trying to get a worker working in an adobe air application, the problem is: the code seems to work in a flash projector, the calls come and go between workersm but when that same code is used in the air app, the call is made to the secondary worker but never returns to the main worker.
Also a trace of Worker.isSupported returns true, so i beliebe this should work.. could this be a sandbox security issue?
I'm compiling for desktop AIR 3.5 -swf-version=18
Copy link to clipboard
Copied
Hi, I've been having some problems with workers and Air and flash 11.5, I had an air application loading a swf and using it as a worker, but it didnt seem to work. I tried that same swf in a flash player, the workers did work there. I then realized the flash version in air was 11.5, and ralized the working loader was a flash 11.4. I updated flash player to 11.5 and then the worker stopped working. I came to realize the actual problem is flash player 11.5.
The same code did work with flash 11.4
any ideas??
Copy link to clipboard
Copied
While debugging, I can't get workers to... work. I've tried it with both FB 4.5 and 4.6, Flash and AIR apps. If I only run them, one example I found on the Internet works (my app may be defective). My SDKs are Flex 4.6 (tried Apache 4.9.1, as well) and AIR 3.8, FP11.8 sa debugger. Any ideas?
Copy link to clipboard
Copied
Hey man_abk, I was just reading this page and came across your question about the workers not working while in debug mode. Just an FYI, this is a known issue that Adobe is tracking here:
https://bugbase.adobe.com/index.cfm?event=bug&id=3578251
Adobe says that workers do not yet exist in debug mode, but will soon.
Copy link to clipboard
Copied
Hi,
Thanks for your comments.
Here i'd like to encounter that any user to has the issue reported in bug https://bugbase.adobe.com/index.cfm?event=bug&id=3578251 drop a vote with comments on how it impact your product or business. Flash Runtime customer experience team will review the bugs periodically and take reference from the vote number to adjust the bug's priority. Thanks!
-Jing
Copy link to clipboard
Copied
A few crucial notes... (AIR 4.0.0, though almost certainly true for all versions)
1. 'MessageChannel.send()' is hideously slow, for things other than sending JUST a ByteArray with shareable set.
If you thought you'd build a message handler that does a lot of small jobs, and followed this terrible, terrible example, and passed the ByteArray as part of an Array, it will pass that by VALUE, regardless of the shareable setting, meaning it will make a complete copy of it. And everything else. And it serializes the AS objects... very... very... VERY slowly.
You're better off serializing your parameters into a single ByteArray for the communication, OR, setting up multiple MessageChannel objects for different kinds of I/O and/or tasks, if you have more than one KIND of thing for your worker to do. But pass ByteArrays with shareable set, to all, either way.
2. WorkerState.RUNNING may be dispatched... instantly. BEFORE your Worker's constructor finishes. Right when you add the event listener. Like 'right now'. Before 'addEventListener' returns. If you were expecting that to happen, like you loaded a swf, and got 'Event.COMPLETE' takes a couple of frames, you're wrong. Worse, other internal initialization can take time. So be sure and make your own 'I finished initializing, REALLY' message, and listen for that.
3. Don't call worker.terminate() in an event listener. Disconnect your listeners, and delay killing it. setTimeout(bgWorker.terminate,500); Unless you like occasional deadlocks.
4. Error trapping in Workers is downright spotty. Sometimes, if you are watching the output, you might see an error message logged. Null object reference, that sort of thing, with a stack dump. The foreground task doesn't stop. These errors are all kinds of potential sources of 'just froze' or 'stopped responding' situations.
5. Try not to reuse those shareable ByteArrays too freely. Yes, it's extra memory allocations and housecleaning, but having a worker and the app reading+writing to the same one, at the same time, is always going to turn out badly. You can set up some locking schemes, but now you're basically preventing the threads from doing the work you jumped through all of these hoops to let them do.
Copy link to clipboard
Copied
Hello Pingnak
I am developing an AIR application in Flex that fetches data from the Server (Through HTTP Services) and store that in the local DB . But when ever application intreact with server , the UI of application gets Hanged.
i read a lot about the Multi threading in Flex using Worker Class but i am not able to use that in my project .
Please help me with working example of Flex AIR application that fetches the data from server (as back ground Process) and store data in Local DB .
Waiting for your answer
Copy link to clipboard
Copied
I am not the right guy to ask about how to use a 'database'. I just half-bake mine from scratch, as needed. I'm a game programmer, not a 'database guy'.
All I would typically do is have some XML to download. Maybe one of several hundred, according to parameters and credentials in the URI? I'm just way too lazy to figure out how to 'database' right, or 'configure a server', so I just bake my own on the spot, and move on. Takes less time than to RTFM about some other person's 'universal, general purpose, one-size-fits-all' gibberish.
Versus, I don't know, read a few tens of thousands of pages of manual, scan the internet for examples (90% of which are broken), and then write tens of thousands of lines of 'scripting' for someone else's general purpose server, in some weird 'web language' that the server supports, chock full of back doors and pitfalls.
I'll roll my own and at least make the 'hackers' do some original work to figure out how to get in, rather than use a standard, pre-baked exploit for a standard, pre-baked database/server that I probably don't ever need to be writeable.