Ошибка времени ожидания при использовании веб-службы CXF из .Net - PullRequest
1 голос
/ 08 февраля 2011

Я работаю с приложением .net, которое использует данные из веб-службы на основе CXF, и я столкнулся с проблемой странного отключения.Несмотря на то, что я установил все соответствующие таймауты, о которых я могу думать с обеих сторон, если запрос занимает больше 30 секунд или около того, то соединение разрывается, и я получаю следующие ошибки

On cxf

    at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:212)
    at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:426)
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:510)
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint.access$000(SelectChannelEndPoint.java:34)
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:450)
    at java.lang.Thread.run(Thread.java:662)
Caused by: com.ctc.wstx.exc.WstxIOException: null
    at com.ctc.wstx.sw.BaseStreamWriter._finishDocument(BaseStreamWriter.java:1431)
    at com.ctc.wstx.sw.BaseStreamWriter.writeEndDocument(BaseStreamWriter.java:553)
    at org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor.handleMessage(SoapOutInterceptor.java:282)
    ... 39 more
Caused by: org.eclipse.jetty.io.EofException
    at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:148)
    at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:92)
    at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:46)
    at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:55)
    at java.util.zip.GZIPOutputStream.writeHeader(GZIPOutputStream.java:123)
    at java.util.zip.GZIPOutputStream.<init>(GZIPOutputStream.java:48)
    at java.util.zip.GZIPOutputStream.<init>(GZIPOutputStream.java:58)
    at org.apache.cxf.transport.common.gzip.GZIPOutInterceptor$GZipThresholdOutputStream.thresholdReached(GZIPOutInterceptor.java:284)
    at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:62)
    at org.apache.cxf.io.CacheAndWriteOutputStream.write(CacheAndWriteOutputStream.java:68)
    at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:100)
    at com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:225)
    at com.ctc.wstx.sw.BufferingXmlWriter.close(BufferingXmlWriter.java:198)
    at com.ctc.wstx.sw.BaseStreamWriter._finishDocument(BaseStreamWriter.java:1429)
    ... 41 more

И ошибка .net

The underlying connection was closed: The connection was closed unexpectedly. ---> System.Net.WebException: The underlying connection was closed: The connection was closed unexpectedly.

, которая, по-видимому, является ошибкой по умолчанию для WCF и является причиной множества различных проблем.

Если я подключаюсь кСлужба CXF с SoapUi, и поставив точку останова в одну из операций, я могу отложить ответ гораздо дольше, чем 30-секундный тайм-аут, и как только ему будет разрешено возобновить, respose проходит без проблем, и это заставляет меня поверитьчто сторона .net выполняет отключение.

Клиент .net настроен со всеми соответствующими таймаутами, и они намного больше, чем 30-секундный, с которым я работаю.

<binding name="serviceBinding" sendTimeout="20:00:00" receiveTimeout="20:00:00" openTimeout="20:00:00" closeTimeout="20:00:00">
    <gzipMessageEncoding />
    <httpTransport manualAddressing="false" decompressionEnabled="False" maxBufferPoolSize="2147483647"     
            maxReceivedMessageSize="2147483647" allowCookies="false" authenticationScheme="Anonymous"
            bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" keepAliveEnabled="true"      
            maxBufferSize="2147483647" proxyAuthenticationScheme="Anonymous"
            realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false" useDefaultWebProxy="true" />
</binding>

Есть ли что-то еще, что могло бы мешать здесь и вызывать разрыв соединения?GzipMessageEncoding не является стандартным, но работает правильно во всех случаях, когда запрос составляет менее 30 секунд.Я очень открыт для любых предложений.

Спасибо

Стив.

1 Ответ

1 голос
/ 08 февраля 2011

Сообщения об ошибках не совпадают, но вы можете посмотреть здесь . В асинхронных операциях есть отдельное время ожидания, которое вы можете настроить только с помощью кода, и это может быть тот, с которым вы работаете (хотя, как я уже сказал, сообщение об ошибке, похоже, не совпадает). Фактические документы здесь .

Возможно, вы также захотите покопаться в WireShark и посмотреть, сможете ли вы поймать фактическое лежащее в основе сообщение об отключении TCP, и посмотреть, какая сторона фактически инициирует разъединение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...