Flex дает ошибку 2032 Stream Stream с IE под нагрузкой
Мы провели поиск в Интернете и нашли сотни сообщений о том же, но ничего из того, что мы нашли, пока не решило эту проблему.
Поэтому, прости меня, чтобы задать этот вопрос еще раз, но нам действительно нужна помощь, чтобы понять, что здесь происходит.
У нас есть гибкое приложение, которое запускается из IE7 со страницы HTML. Как только приложение SWF запущено, оно выполняет несколько обращений к внутренним java-сервисам (работает в Weblogic 10) для получения информации. И это работает очень хорошо.
Теперь проблема в том, что я открываю несколько таких экземпляров на одном и том же клиенте, например, открывая несколько вкладок или несколько окон IE7. Тогда мы получаем #2032 Ошибки потока.
[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]
Теперь, если я наберу http: // имя_сервера: порт / Myservice [игнорировать пробелы]
в IE7 он идет в сервис без проблем. Таким образом, URL-адрес правильный.
Если я вызываю ту же службу через SOAP UI, это время от времени дает мне ответ.
Наиболее близкое, что я мог найти решение, находится на сайте.
http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/
Где это указывает, что мы должны изменить стратегию кэширования в заголовках HTML, который запускает экран.
Поэтому мы добавили тег META ко всем нашим HTML-страницам.
<head>
<META Http-Equiv="Cache-Control" Content="no-store">
Но используя wireshark, я все еще вижу в ответах, которые возвращаются, что для элемента управления кэшем задано значение no-cache (в конце фрагмента кода), а не no-store, как указано в 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
Знаете ли вы, решит ли это нашу проблему или что мы делаем неправильно?
- Некоторые дополнительные ответы на использование и использование браузера
Это было проверено только с использованием IE7 и Firefox (не помню версию). Наша компания поддерживает IE, а не Firefox. Следовательно, мы не можем перейти на Firefox. Однако мы попробовали это и на Firefox. Это случается не так часто. На IE 2 из 4 не получается. На Firefox мы подняли его примерно до 2 из каждых 12 неудач.
Это было проверено только с использованием IE7 и Firefox (не помню версию). Наша компания поддерживает IE, а не Firefox. Следовательно, мы не можем перейти на Firefox. Однако мы попробовали это и на Firefox. Это случается не так часто. На IE 2 из 4 не получается. На Firefox мы подняли его примерно до 2 из каждых 12 неудач. То, что я читаю в сети (и я так не эксперт в этом вопросе). При каждом обращении к серверу браузер имеет возможность кэшировать этот ответ. Теперь, если я открою несколько экранов браузера, открывающих один и тот же процесс - например, в каждом окне IE будут выполняться одинаковые вызовы... Каким-то образом эти ответы перепутаны. Теперь, что этот парень предложил в URL. Разве мы установили опцию кэширования в заголовке, чтобы не кэшировать. Таким образом, ответ будет только тогда, когда он необходим, и, следовательно, не может быть перепутано.
Наши пользователи не используют систему таким образом. Но время от времени они получают одно и то же сообщение об ошибке. Они утверждают, что не открывают несколько сессий. Но это был пока единственный способ, которым мы могли воссоздать его.
Что касается брандмауэра... Не уверен, что это может быть проблемой, поскольку он работает в IE и Firefox и SoapUI хотя бы один раз.
1 ответ
На IE (несколько версий мы не могли найти проблему).
Но мы нашли обходной путь.
В итоге мы использовали HttpManager с очередью. Все запросы мы добавляем в очередь. Затем HttpManager выполнит первые 4 запроса и, получив ответ, просматривает ответ и, если произошла ошибка 2032, повторяет его 3 раза, а затем, наконец, останавливается, отображает ошибку и продолжает следующий запрос в очереди.
Ограничивая максимальное количество одновременных запросов, мы едва ли когда-либо пытались повторить его, но в некоторых крайних тестовых случаях нам приходилось повторять только дважды. Так что 3 раза было более чем достаточно.
Мы также поиграли с количеством запросов на симуляцию и в итоге оставили его равным 4. Увеличение его числа увеличивает общее время выполнения всех вызовов.