In Flex 3 application I use HTTPService class to make requests to the server:
var http:HTTPService = new HTTPService();
http.method = 'POST';
http.url = hostUrl;
http.resultFormat = 'e4x';
http.addEventListener(ResultEvent.RESULT, ...);
http.addEventListener(FaultEvent.FAULT, ...);
http.send(params);
The application has Comet-architecture. So it makes long running requests. While waiting a response for this request, other requests can be made concurrently.
The application works in most cases. But sometimes some clients get HTTP request error executing long running request:
faultCode:Server.Error.Request
faultString:'HTTP request error'
faultDetail:'Error: [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2032"]. URL: http://example.com/ws'
I think it depends on user's browser.
Any ideas?
Try listening for the HTTP-status of the request, using
flash.events.HTTPStatusEvent.HTTP_STATUS
That might give you some more info about what's going wrong.
This error appears very generic and I would suggest trying to collect more information and sharing it regarding the issue.
I was going to open another question on essentially the same topic, but I figure two unanswered questions is worse than 1.
I get a similar intermittent issue from some users of a Flex application we have, but with some slightly different symptoms. The full range of information I can provide is:
The current workaround we have is to request users run the application in FireFox.
Full dump of the error is:
Many people have mentioned error 2032, a few even mentioning intermittent errors under IE only, but there are no mentions of the solution. If I ever find one, I'll update my post here.
Update
After talking to a user as this occurred, we found the following:
It appears that in my particular application, my flex app manages to break the flash plugin/VM to such an extent that after the break, no further requests to the URL are allowed.
I am so completely stumped by this I'm at the point of suggesting users use FireFox, or wrapping the application in an Air package.
Sounds like you might have more connections going out then the browser supports. Do you know exactly how many open connections exist at the time of the error?
Different browser allow different numbers of simultaneous open connections. IE 6,7,8 all allow different amounts: http://support.microsoft.com/kb/282402
Firefox: http://www.speedguide.net/faq_in_q.php?qid=231
I've had this exact issue happening in my Air app. I eventually realized that I had accidentally set the
urlrequest.idleTimeout
to 10. This timeout is actually in milliseconds and my webserver is local, so if I sent no parameters (no get or post) to my local server it would work. Whenever I sent any parameters along with the request of course it would fail because my script took longer than 10ms to run and return the data.You may want to pay attention to slow loading scripts. You can debug by just forcing some static output and then stop that page from executing further. In my php page I put:
Also, make sure to debug it within the sandbox limitations. I am using a self-signed ssl cert and there are a lot of warnings when trying to connect to my local test webserver.
Hope that helps!
I had somewhat the same problem here but with a Flash (Web - Flex 4.1 SDK) application. after trying out a huge assortment of solutions we narrowed we finally came up with one that works pretty reliably for all systems, including newly installed machines.
A. add global event listeners at the root (or stage) of the application, on flex preinitialize stage.
if an error is cought -
event.preventDefault();
B. add event listeners on every loader used in the App for the following errors:
*to attempt recovery, like falling back to an external interface call...
C. place all the SWZ files from the bin-release folder together with the SWF file in the same path on the server you use to deliver your App. in my case these are the files needed:
* to discover this i used Chrome developer console to see which errors occur on the page and discovered a chain of 404s when the app tries to download these files.
D. have a properly configured crossdomain.xml policy file which includes the allow http request xml tag.
replace the * as needed in your particular case.
Cheers