Улучшите чтение ответов веб-службы на стороне клиента с помощью AxiomSoapMessageFactory.

В настоящее время мы называем веб-сервисы SOAP, которые возвращают очень большие ответы.

Мы используем Spring-WS (используя WebServiceTemplate), клиент JAX-WS при вызове веб-служб, а приложение запускается на Jboss EAP 6.0.

В настоящее время мы также используем SaajSoapMessageFactory. Я прочитал на форумах, что следует использовать AxiomSoapMessageFactory, а не SaajSoapMessageFactory (http://docs.spring.io/spring-ws/site/reference/html/common.html), чтобы повысить эффективность чтения.

Я сделал следующую модификацию:

Заменены

<bean id="messageFactory" class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory"> 
        <property name="soapVersion">
            <util:constant static-field="org.springframework.ws.soap.SoapVersion.SOAP_11" />
        </property>
    </bean>

by

 <bean id="messageFactory" class="org.springframework.ws.soap.axiom.AxiomSoapMessageFactory">
        <property name="payloadCaching" value="true"/>
    </bean>

Это изменение сработало нормально, как и ожидалось. Однако ссылка, о которой я упоминал выше, предлагала установить следующее:

 <property name="payloadCaching" value="false"/>

После того, как я установил этот параметр и когда веб-служба была вызвана, я получаю следующее исключение:

org.springframework.ws.soap.axiom.AxiomSoapBodyException: Could not access envelope: null; nested exception is org.apache.axiom.om.NodeUnavailableException: org.springframework.ws.soap.axiom.AxiomSoapBodyException: Could not access envelope: null; nested exception is org.apache.axiom.om.NodeUnavailableException
    at org.springframework.ws.soap.axiom.AxiomSoapEnvelope.getBody(AxiomSoapEnvelope.java:97) [:2.2.0.RELEASE]
    at org.springframework.ws.soap.AbstractSoapMessage.getSoapBody(AbstractSoapMessage.java:38) [:2.2.0.RELEASE]
    at org.springframework.ws.soap.AbstractSoapMessage.getPayloadSource(AbstractSoapMessage.java:50) [:2.2.0.RELEASE]
    at org.springframework.ws.support.MarshallingUtils.unmarshal(MarshallingUtils.java:55) [:2.2.0.RELEASE]
    at org.springframework.ws.client.core.WebServiceTemplate$3.extractData(WebServiceTemplate.java:413) [:2.2.0.RELEASE]
    at org.springframework.ws.client.core.WebServiceTemplate.doSendAndReceive(WebServiceTemplate.java:616) [:2.2.0.RELEASE]
    at org.springframework.ws.client.core.WebServiceTemplate.sendAndReceive(WebServiceTemplate.java:555) [:2.2.0.RELEASE]
    at org.springframework.ws.client.core.WebServiceTemplate.marshalSendAndReceive(WebServiceTemplate.java:390) [:2.2.0.RELEASE]
    at org.springframework.ws.client.core.WebServiceTemplate.marshalSendAndReceive(WebServiceTemplate.java:383) [:2.2.0.RELEASE]
    at org.springframework.ws.client.core.WebServiceTemplate.marshalSendAndReceive(WebServiceTemplate.java:373) [:2.2.0.RELEASE]

Любые идеи о том, почему эта ошибка? Я пропустил изменение какой-либо другой опции или это несовместимость файлов библиотеки, которые я использовал.

Еще один вопрос:


После комментирования моих записей log4j, связанных с og4j.logger.org.springframework.ws.client.MessageTracing, я смог успешно использовать веб-службу. Также провел тест производительности и обнаружил, что для теста с 50 пользователями, одновременно обращающимися к веб-службе (косвенно через экран, который, в свою очередь, вызывает веб-службу), общее время отклика (с момента нажатия кнопки до момента ответа от веб-служба снова отображается на экране) сокращено с ~ 27 секунд до 22 секунд — это хорошее улучшение на 5 секунд по сравнению с SaajSoapMessageFactory. Однако, когда я провел тест на 100 пользователей, время отклика увеличилось на 2 секунды, и SaajSoapMessageFactory в этом случае оказался лучше. Может ли кто-нибудь объяснить причину этой разницы в производительности, несмотря на то, что AxiomSoapMessageFactory использует потоковую передачу и избегает построения дерева??


person user2253556    schedule 21.07.2014    source источник
comment
Просто прокомментировал приведенные ниже строки в моем log4j, и проблема, похоже, решена СЛЕД   -  person user2253556    schedule 22.07.2014


Ответы (1)


payloadCaching=false указывает Axiom не строить дерево объектной модели для полезной нагрузки. Это то, что обеспечивает прирост производительности, но также подразумевает, что доступ к полезной нагрузке возможен только один раз. В более старых версиях Axiom попытка доступа к полезной нагрузке во второй раз приведет к несколько неясному OMException. В последних версиях он вызывает NodeUnavailableException, который задокументирован в Javadoc. Как вы отметили в своем комментарии, в вашем случае полезная нагрузка потребляется ведением журнала трассировки.

person Andreas Veithen    schedule 22.07.2014