9 Replies Latest reply on Dec 17, 2008 4:18 PM by enorton@adobe

    Network failure not firing event on standby

    kstephens2
      I have a long running AIR app doing file uploads. If the machine goes to sleep/standby mode for more than a short period of time the file uploads stop and don't recover. We have tracked it down to the point where the network card stops responding. Some times this will fire an air.IOErrorEvent.IO_ERROR event correctly and we get a #2308 I/O error. Other times no event is fired. As a result the code doesn't know to move on to the next file.

      Does anyone know what event we are missing to tell us that a file has stopped sending data?

      We are watching:
      air.ProgressEvent.PROGRESS
      air.DataEvent.UPLOAD_COMPLETE_DATA
      air.SecurityErrorEvent.SECURITY_ERROR
      air.HTTPStatusEvent.HTTP_STATUS
      air.IOErrorEvent.IO_ERROR

      And none of them are being fired when this occurs. We are causing this to happen by putting the windows machine into standby and waiting for a few minutes and/or pulling the network cable on the machine mid file.upload()

      Any help would be greatly appreciated.
        • 1. Re: Network failure not firing event on standby
          kstephens2 Level 1
          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()?
          • 2. Re: Network failure not firing event on standby
            tzeng Adobe Employee
            Could you file a bug at:
            www.adobe.com/go/wish/

            Thanks,

            -ted
            • 3. Re: Network failure not firing event on standby
              enorton@adobe Level 1
              Hi,

              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?

              Thanks!
              • 4. Re: Network failure not firing event on standby
                kstephens2 Level 1
                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.
                • 5. Re: Network failure not firing event on standby
                  kstephens2 Level 1
                  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.

                  • 6. Re: Network failure not firing event on standby
                    kstephens2 Level 1
                    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.
                    • 7. Re: Network failure not firing event on standby
                      tzeng Adobe Employee
                      Thanks for sharing the workaround.

                      -ted
                      • 8. Re: Network failure not firing event on standby
                        kstephens2 Level 1
                        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.
                        • 9. Re: Network failure not firing event on standby
                          enorton@adobe Level 1
                          Hi,

                          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!

                          -Erica