Flex giving Error 2032 Stream Error with IE under load

StackOverflow https://stackoverflow.com/questions/14397963

Question

We have searched the web and found 100’s of posts regarding the same thing but nothing that we’ve found resolved this issue as to yet.

Therefore forgive me to ask this question again but we really need help to understand what is going on here.

We have flex app that is launched from IE7 from a HTML page. Once the SWF app is launched it makes several calls to backend java services (Running on Weblogic 10) to retrieve information. And this works very well.

Now the problem is when I open up several of these instances on the same client… e.g. either by opening up multiple tabs or by multiple IE7 windows. Then we get #2032 Stream errors.

[FaultEvent fault=[RPC Fault faultString="HTTP request error" 
faultCode="Server.Error.Request" faultDetail="Error: [IOErrorEvent type="ioError" 
bubbles=false cancelable=false eventPhase=2 text="Error #2032: Stream Error. 
URL: http://ServerName:Port/Myservice"]. URL: http:// ServerName:Port/Myservice"]     
messageId="CA4B34AD-7A46-461E-7C6F-4D618ED0A112" type="fault" bubbles=false 
cancelable=true eventPhase=2]

Now if I type out the http: // ServerName : Port / Myservice [ignore the spaces]

in IE7 it goes to the service without any issues. So the url is correct.

If I call the same service via SOAP UI it gives me a response time after time.

The closest that I could found of a solution is on the site

http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/

Where it indicates that we should change the caching strategy in the HTML headers that launches the screen.

We therefore added the META tag to all our HTML pages

<head>
<META Http-Equiv="Cache-Control" Content="no-store">

But using wireshark I can still see in the responses that come back that cache-control is set to no-cache (at the end of the code snippet) and not to no-store as specified in the HTML.

POST /MyService/MyService HTTP/1.1 Accept: */* Accept-Language: en-US x-flash-
version:     
10,3,183,20 Content-Type: text/xml; charset=utf-8 SOAPAction: "" Content-Length: 528 
Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows 
NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 
3.0.30729; Media Center PC 6.0; InfoPath.2; .NET4.0C; .NET4.0E) Host: dhtqawl01:8081 
Connection: Keep-Alive Cache-Control: no-cache

Do you know if this will solve our problem or what we might be doing wrong?

--Some extra response on usage and browser usage

This was only tested using IE7 and Firefox (can't remember the version). Our company supports IE and not Firefox. Hence we can't move to Firefox. We did however tried it on Firefox as well. It doesn't occur that often. On IE 2 out of 4 fails. On Firefox we pushed it up to about 2 out of every 12 fails.

This was only tested using IE7 and Firefox (can't remember the version). Our company supports IE and not Firefox. Hence we can't move to Firefox. We did however tried it on Firefox as well. It doesn't occur that often. On IE 2 out of 4 fails. On Firefox we pushed it up to about 2 out of every 12 fails. What I read on the net (and I am so not an expert on this matter). With every call that is made to the server the browser has the option to cache that response. Now if I open up multiple browser screens opening the same process - e.g. the same calls will be made by every IE window... Somehow these responses get mixed up. Now what this guy suggested in the URL provided. Is that we set the cache option in the header not to be cached. That way the response will only be there when it is required and hence no mix up can be made.

Our users don't use the system in this way. But from time to time they do get the exact same error message. They state that they don not open multiple sessions. But this was so far the only way that we could recreate it.

As to the firewall... Not sure if this can be the problem since it works in IE and Firefox and SoapUI at least once.

Était-ce utile?

La solution

On IE (several versions we could not find the issue).

But we did find a workaround.

We ended up using an HttpManager with a queue. All the requests we add to a queue. The HttpManager will then execute the first 4 requests and as it gets a response, it looks at the response and if a 2032 Error occurred, retries it 3 times and then finally stops and display the error and continue with the next request in the queue.

By throttling the maximum number of simultaneous requests we hardly ever had to retry it but in some extreme test cases we only had to retry twice. So 3 times were more than enough.

We also played around with the number of simulations requests and we ended up keeping it at 4. Increasing it increase the total time to make all the calls.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top