«задержка» доставки ответа WebService при использовании sun HttpServer - PullRequest
Новая
       31

«задержка» доставки ответа WebService при использовании sun HttpServer

1 голос
/ 18 декабря 2011

Я пишу отдельное приложение, которое реализует веб-службу, для которой конечная точка публикуется с использованием встроенного Sun HttpServer. У меня странная проблема с этим, когда в конкретной ситуации развертывания существует очевидная задержка между сервером , обрабатывающим / отправляющим ответ, и клиентом , получающим ответ.

Позвольте мне привести несколько сценариев:

Случай 1) Работает: сервер работает внутри Eclipse, который использует OpenJDK 1.6.0_23 в качестве среды выполнения. Клиент реализован с осью (не axis2!) И работает на Solaris x86 внутри JBoss (должен признать, что я не знаю точную используемую версию Java, но подозреваю версию Java 5).

Случай 2) Работает: сервер работает на Solaris x86 с java 1.6.0_26, клиент работает в Eclipse с OpenJDK 1.6.0_23.

Случай 3) Не работает: сервер работает на Solaris x86 с java 1.6.0_26, клиент на Solaris x86 с осью на Solaris x86 (опять же, подозреваю, что это Java 5, а не 6).

Мне интересно, мог ли я страдать от следующей ошибки Java, которая исправлена ​​в 1.6.0_30 (при условии, что OpenJDK 1.6.0_xx не страдает той же ошибкой)?

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068416

Но если это так, то почему бы работать вариант 2? Может ли клиент каким-либо образом управлять TCP_NODELAY на стороне сервера ?

О точных задержках, которые я наблюдал: у меня есть 2 веб-сервиса, опубликованные в разных контекстах. Например, 2 разных WSDL. Клиент имеет (очевидно) отдельные (ось 1) привязки для каждого сервиса. Для одного сервиса я вижу постоянную задержку ровно в 150 секунд, для другого сервиса задержка составляет неизменно 300 секунд. Эти ценности кому-нибудь звонят?

Маартен

Редактировать Сейчас я склоняюсь к причине и решению проблемы в Eclipse Generated Web Service Client, чрезвычайно медленном . Не могу проверить в данный момент, так как я сижу в номере отеля без доступа к системе.

1 Ответ

0 голосов
/ 19 декабря 2011

ОК, удалось решить эту проблему, сказав Axis использовать CommonsHttpSender вместо HttpSender по умолчанию.Поскольку в соответствующем приложении уже есть необходимые jar-файлы для этого в каталоге WEB-INF / lib, это не было большой проблемой.

Чтобы заставить Axis (1.4) использовать CommonsHttpSender, создайте «клиент-config.wsdd "файл в следующем месте (примечание: это была неочевидная часть, которая вызывала у меня немало головных болей): 

MY.ear/MY.war/WEB-INF/classes/org/apache/axis/client/client-config.wsdd

со следующим содержимым: 

<?xml version="1.0" encoding="UTF-8"?> 
<deployment 
    name="commonsHTTPConfig" 
    xmlns="http://xml.apache.org/axis/wsdd/" 
    xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

   <!-- use CommonsHTTPSender instead of the default HTTPSender -->
  <transport name="http" pivot="java:org.apache.axis.transport.http.CommonsHTTPSender" />  

  <transport name="local" pivot = "java:org.apache.axis.transport.local.LocalSender" /> 
  <transport name="java" pivot="java:org.apache.axis.transport.java.JavaSender" /> 
</deployment>

Перезапустите приложение.После этого изменения Axis будет использовать HTTP / 1.1 для вызовов веб-служб, что, по-видимому, является всем необходимым для исправления этой раздражающей задержки.Похоже, в спецификациях протокола HTTP (или, возможно, в реализации Axis) есть что-то , которому не нравится ответ HTTP / 1.1 на запрос HTTP / 1.0.

Maarten

...