Нет обмена сообщениями SOAP между клиентом Metro и службой WCF на 64-разрядных версиях Win7 и Windows 2008 Server.

У меня есть работающее соединение веб-службы между клиентской программой Java со стеком веб-службы Metro {2.2.1-1} и веб-службой WCF {.NET 4.0 v30319} wsHttpBinding в Windows XP SP3.

Если я перенесу точно такую ​​же настройку на Windows 7 {с некоторой корпоративной настройкой} или Windows 2008 R2 Server SP1 {с MS DVD}, я получаю зависшие запросы от клиента Java к службе WCF. т.е. нет признаков какого-либо обмена данными между двумя партнерами {у меня есть -Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true на стороне клиента и диагностические сообщения печати на стороне сервера - оба без вывода}. С точки зрения сети TCP-соединение открыто ("netstat -a") до тех пор, пока через 200+-5 секунд не произойдет тайм-аут со следующей трассировкой стека:

Jul 19, 2013 12:13:00 PM ch.xxxxxxxx.xxxxx.balance.client.start.Start main
SEVERE: null
com.sun.xml.ws.streaming.XMLStreamReaderException: XML reader error: com.ctc.wstx.exc.WstxIOException: Connection reset
    at com.sun.xml.ws.streaming.XMLStreamReaderUtil.wrapException(XMLStreamReaderUtil.java:326)
    at com.sun.xml.ws.streaming.XMLStreamReaderUtil.next(XMLStreamReaderUtil.java:99)
    at com.sun.xml.ws.streaming.XMLStreamReaderUtil.nextContent(XMLStreamReaderUtil.java:169)
    at com.sun.xml.ws.streaming.XMLStreamReaderUtil.nextElementContent(XMLStreamReaderUtil.java:104)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:584)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:470)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseImport(RuntimeWSDLParser.java:427)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseImport(RuntimeWSDLParser.java:835)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:464)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:232)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:192)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:161)
    at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:328)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:290)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:217)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:199)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:195)
    at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:112)
    at javax.xml.ws.Service.<init>(Unknown Source)
    at ch.xxxxxxxx.xxxxx.balance.client.SystemIntegrationServiceBridge.<init>(SystemIntegrationServiceBridge.java:50)
    at ch.xxxxxxxx.xxxxx.balance.client.start.Start.main(Start.java:37)
Caused by: com.ctc.wstx.exc.WstxIOException: Connection reset
    at com.ctc.wstx.sr.StreamScanner.constructFromIOE(StreamScanner.java:625)
    at com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1049)
    at com.ctc.wstx.sr.StreamScanner.parseLocalName2(StreamScanner.java:1857)
    at com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1817)
    at com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2925)
    at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2817)
    at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1065)
    at com.sun.xml.ws.util.xml.XMLStreamReaderFilter.next(XMLStreamReaderFilter.java:96)
    at com.sun.xml.ws.streaming.XMLStreamReaderUtil.next(XMLStreamReaderUtil.java:80)
    ... 19 more
Caused by: java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(Unknown Source)
    at java.net.SocketInputStream.read(Unknown Source)
    at java.io.BufferedInputStream.fill(Unknown Source)
    at java.io.BufferedInputStream.read1(Unknown Source)
    at java.io.BufferedInputStream.read(Unknown Source)
    at sun.net.www.MeteredStream.read(Unknown Source)
    at java.io.FilterInputStream.read(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown Source)
    at com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
    at com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
    at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
    at com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:87)
    at com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:57)
    at com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1046)
    ... 26 more

Если я завершу службу в течение этого периода, клиент немедленно прекратит ожидание с аналогичной трассировкой стека, и, как и ожидалось, TCP-подключение больше не существует.
Активация ведения журнала WCF (см. http://msdn.microsoft.com/en-us/library/ms730064.aspx) показывает журнал в соответствии с которому WCF считает, что он полностью и успешно доставил три части WSDL (/?wsdl, /?wsdl=wsdl0, /?wsdl=wsdl1).
Все работает от имени администратора, UAC выключен, не имеет значения, включен ли у меня брандмауэр или включен или выключен IPv6. Я пробовал JRE 7_u17 32-битную, 7_u25 32-битную и 7_u25 64-битную.

SoapUI 4.5.1 отлично взаимодействует со службой локально на платформе win7-oid.
Клиент WCF взаимодействует со службой локально и без прокси-сервера.
Небольшой клиент веб-службы Java, использующий библиотеки Metro, вызывающий соответствующая веб-служба WCF локально работает нормально.
Если я установлю http-прокси-сервер Fiddler на платформах win7-oid и перенастрою свое клиентское приложение Java для использования прокси-сервера {-Dhttp.proxyHost=localhost -Dhttp.proxyPort=8888 - Dhttp.nonProxyHosts=""}, все в порядке.
Если клиентская часть находится на коробке XP, а служба на W7oid и наоборот, удаленный доступ к службе WCF работает нормально, без всяких ухищрений.< бр/>

Исчерпав воображение, что может быть причиной такого странного поведения, я хотел бы задать следующие вопросы:
- есть ли кто-нибудь, кто сталкивался с похожей проблемой
- есть предложения, которые Механизм Windows может мешать описанным образом
- любые предложения, какие другие эксперименты я мог бы предпринять, чтобы приблизиться к решению
- какие дополнительные диагностические меры я должен предпринять, чтобы свести это к самой проблеме [ и решение, я надеюсь]




Ответы (2)


Вышеуказанные симптомы показывают, что проблема

  • возникает во время извлечения [частей] WSDL
  • происходит при прямом использовании сетевого подключения W7oid.

Это привело к дальнейшему анализу того, что произошло на уровне TCP. Прежде всего, невозможно было увидеть локальный IP-трафик моего подключения к веб-службе с Wireshark 1.10.2. Даже IP-трафик через физический IP-интерфейс не был виден. Также большинство других хоть как-то свободно доступных сетевых анализаторов вроде бы не поддерживали анализ IP-трафика на петлевом интерфейсе W7 и Windows 2008 Server.

Наконец, я смог получить больше информации с пробными версиями CommView и LocalNetworkMonitor:

  • также IP-трафик, настроенный на использование физического IP-интерфейса, [тайно] маршрутизируется через локальный сетевой стек, как если бы это было петлевое соединение.
  • такой петлевой IP-трафик, по-видимому, работает на технически другом стеке IP на платформах W7oid. В противном случае инструменты не различали бы эти две ситуации.
  • на уровне TCP клиент начинает с открытия соединения http-TCP для получения «?wsdl». ("?wsdl" содержит ссылки на два больших файла wsdl "?wsdl=wsdl0" и "?wsdl=wsdl1") Затем, почти одновременно, клиент запрашивает "?wsdl=wsdl0" в том же первом TCP-соединении (вероятно, из-за для поддержания активности) и вновь открытое второе TCP-соединение. Одно из этих двух подключений остается непрочитанным и незавершенным. Только после тайм-аута около 200 секунд в пути появляется некоторый дополнительный фрагмент данных, и оба TCP-соединения закрываются (сразу же следует трассировка клиентского стека выше).

Выводы:
По крайней мере, с HTTP-keep-alive, который является стандартной настройкой для WCF и Metro, сервер W7 и W2k8 обрабатывает HTTP-TCP-трафик через интерфейс обратной связи и так, как этого ожидают WCF и Metro. , не стыкуются.
В заданном объеме свести к самой причине не удалось. Тем не менее, похоже, что сетевой стек обратной связи W7 очень требователен. Даже у инструментов мониторинга сети есть серьезные проблемы, чтобы предложить правильно работающие решения.

Обходной путь...
... состоял в том, чтобы настроить канал веб-службы на физический IP-интерфейс И установить высокоприоритетный IP-маршрут на устройстве W7/W2k8, который направляет трафик на этот интерфейс через IP-шлюз. Только тогда W2k8 мог бы быть вынужден воздержаться от закольцовывания и действительно доставлять IP-трафик на физический сетевой интерфейс через свой «обычный» IP-стек — на котором все, т.е. веб-сервис и инструменты, работает нормально.

person mr_mda    schedule 28.04.2014

Вы уверены, что все соединения закрываются правильно? Симптомы, которые вы описываете, часто наблюдаются в мире .NET, когда .Close() забывается в предыдущем потоке ответов.

При более поздних запросах клиент блокируется, ожидая, пока соединение станет доступным (из-за ограничения HTTP-соединения). http://fiddler2.com/blog/blog/2013/02/28/help!-running-fiddler-fixes-my-app-

person EricLaw    schedule 25.07.2013