1 Reply Latest reply on Aug 22, 2008 8:59 AM by Oliver Goldman

    Webkit timeout kills long running tasks

      Hi There

      We have just been forced to refactor/recode a significant portion of one of our AIR based RIA's due to an arbitrary decision made by the Webkit team to restrict all XML HTTP requests via a hard coded, hidden timeout of 60 seconds. This decision not only affects AIR but also affects Safari and other browsers based upon Webkit.

      Our application performs complex analytic queries which may run to a few minutes. Whilst long synchronous requests are not generally a good idea for web based solutions, we believe that RIA intranet applications are a completely different ball game and should not be subject to arbitrary constraints such as these with no flexibility or warning. We would not see this behaviour in Java / C# or other such application languages, so why are we seeing this in Adobe AIR?

      Our MD has understandably questioned the suitability of Adobe AIR for future developments of enterprise RIA's, and we are all naturally concerned about other "features" being added or removed to the Adobe AIR functionality, even indirectly and whether in fact we can rely upon Adobe to monitor the stability of their runtime. We don't believe it is acceptable for us to tell our customers that it was the fault of a component nested within multiple layers of the runtime outside of our control and believe that it is equally unacceptable for Adobe to stand by and claim the same.

      We are excited about the prospects of investing in Adobe AIR for delivering rapid RIAs to our customers, but are we to expect similar show stoppers to arise over the coming months or even years, and can we trust the Adobe runtime as an "In production" solution going forward.

      Mark Robertshaw
      Oxford Information Labs
        • 1. Re: Webkit timeout kills long running tasks
          Oliver Goldman Adobe Employee

          Thanks for bringing this to our attention. We, as I'm sure you realize, aren't claiming that this sort of thing is ok. And we do work hard to maintain the stability of the runtime. However, it can be difficult to know a priori everything that we need to keep an eye on. That's one of the reasons we have forums like this one and we very much appreciate this kind of feedback.

          As for this particular issue, I'll just point out that you might consider taking advantage of the flash.net.* APIs to manage your network request, at least as a temporary workaround.

          Oliver Goldman | Adobe AIR Engineering