This content has been marked as final. Show 9 replies
We tried using URLMonitor and air.Event.NETWORK_CHANGE but they don't always detect the standby. They do work for pulling the network cable and sometimes for going into standby but it doens't fire when standby returns.
Has anyone else dealt with the machine going into standby during file.uploads()?
Could you file a bug at:
Could you please provide some more detailed information.
When you say for a "short period of time" do you mean at least 30 seconds, 5 minutes, 1/2 hour?
Are you talking about large files - what's the average/largest/smallest size?
What platform(s) have you seen this behavior on?
I just submitted a bug.
"short period of time" seems to be a minimum of about 15 seconds. Any less and the upload does recover and move on. Great than 15 seconds and it will do one of two things:
1. it will throw a #2038 ioerror ( appears to be the generic error for any type of io issue and throws also for read permissions and server unreachable )
2. it will do nothing. It will just hang never firing any of the events related to upload.
Size of the file doesn't appear to matter. I am running this against a long list of random files and I can't recognize a pattern in their sizes.
I have only seen this on Windows XP, but that is all I have access to for testing this issue.
I just ran some more tests and it seems that this is occurring when the standby mode hits when a file is at 100% uploaded. So my current theory is that it is firing the upload_complete_data event right as the standby hits so the listeners never get it because of the standby. It took me 30 tries before I was able to trigger the bug so it is quite elusive.
Playing more but I might back a timer that fires when standby is done and sees if a file is stuck at 100% complete and manually runs the method the upload_complete_data event would have triggered.
So I came up with a convoluted solution to this issue:
I set a timer when a file.upload() begins and reset it each progress event. Or clear it every complete or error event. If 20 seconds goes by with no progress, complete or error event I then set a second timer and wait for another 10 seconds and then move onto the next file. The first timer will detect the standby and the secondary timer gives the file.upload() time to error after the standby. If the file.upload() recovers or errors after the standby it clears the secondary timer.
This seems to be a workaround but I would still like to see the bug fixed where standby or network failure at 100% completed causes file.upload() to not throw and error or complete event.
Thanks for sharing the workaround.
The workaround didn't really work. Looks like some of the lockups where events aren't firing can also be replicated by having the server sleep for greater than 30 seconds. The socket is closed, but the file.upload() never fires any events.
This is not an unrealistic consideration when you consider PHP has to move the file from /tmp/ to the final resting place. So if you have a multiple GB file it can take PHP considerable amounts of time to move the file and the apache could easily linger for more than 30 seconds in which case the air app just hangs.
So I got your bug report on the 30 second issue, and that in and of itself didn't cause events to not fire for me. (I added a 31 second delay on my remote page that handled the upload.) However, I did indeed see a problem when the server becomes disconnected from the network. Though it seems like no events fire, it just takes a _really_ long time. 60 minutes. That does seem a bit too long :) There's now a bug filed for this.
(We also have the whole stand by mode issue logged)
Thanks for helping us by tracking things down!