Проблема производительности Axis2 getSOAPEnvelope () - PullRequest
Новая
       5

Проблема производительности Axis2 getSOAPEnvelope ()

1 голос
/ 16 июня 2011

Используя axis2 в Solaris, я заметил, что вызов message.getSOAPEnvelope () максимизирует обработку сервера до 0.0 в режиме ожидания.Вызов занимает около 10 секунд, а затем нагрузка обработки возвращается к нормальной.Это безумие для одного метода, особенно для чего-то, встроенного в Axis.

Может кто-нибудь предложить решение этой проблемы, я не смог найти ничего похожего в Интернете. 

// get message for sending
Message message = getSOAPMessage();
...
message=signSOAPEnvelope(message.getSOAPEnvelope()); //problem
...
SOAPEnvelope retMsg = (SOAPEnvelope) call.invoke(message.getSOAPEnvelope()); //problem

- ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ ---

Хорошо, поэтому проблема заключается в методе SAXParser.parse (), который вызывается по оси (а не по оси2, кстати).Поэтому я провел еще несколько тестов с другими сообщениями.

Мое приложение создает SoapEnvelope и к нему добавляется тело сообщения.Я получил сообщение от другого приложения, которое, как я знаю, работает, и после сборки мыльного конверта я переопределил строку сообщения этим более старым XML.Таким образом, SoapEnvelope идентичен в обоих случаях, однако XML, который я взял из другого проекта, работает хорошо, в то время как мой новый XML не работает.Сумасшедшая вещь в том, что старый XML больше, поэтому должен занять больше времени.Ниже приведены примеры соответствующего xml, поскольку я не могу понять, почему один должен работать, а другой нет.

РАБОТАЕТ ОК: большой старый xml 

    <ns2:applicationDetailSearchQuery 
   xmlns:ns2="http://www.company.com.au/wib/ID/schema/query" 
xmlns:ns3="http://www.company.com.au/wib/Counterparty/schema/query"
xmlns:tns="http://www.company.com.au/wib/icc/schema/query">

<tns:queryID scheme="http://www.company.com.au/treasury/idbb/queryid">44051</tns:queryID>
<tns:queryType>ApplicationDetailSearch</tns:queryType>
<tns:pageSize>10000</tns:pageSize>
<ns2:parameters>
    <ns2:tradeIdList>
        <ns2:tradeId>111111</ns2:tradeId>
    </ns2:tradeIdList>
    <ns2:queryByHeadDealId>N</ns2:queryByHeadDealId>
    <ns2:retrieveSchedule>N</ns2:retrieveSchedule>
    <ns2:retrieveCashFlowDeals>Y</ns2:retrieveCashFlowDeals>
    <ns2:dealType>BOND</ns2:dealType>
 </ns2:parameters>
</ns2:applicationDetailSearchQuery>

ДЕЙСТВИТЕЛЬНО МЕДЛЕННО: маленький xml??? 

<ns5:querySetRequest setId="1" xmlns:ns2="http://schemas.company.com.au/ttt/icc/common/header-V2-0" xmlns:ns4="http://schemas.company.com.au/ttt/icc/Services/FXC/TradeEnquiryServiceEnvelope" xmlns:ns3="http://schemas.company.com.au/ttt/icc/common/envelopemsg-V2-0" xmlns:ns5="http://webservice.common.ttt/queryservice/types">
<ns5:query queryName="RemainingBalanceQuery" queryID="1">
    <ns5:parameter value="FWD:169805" type="String" name="KondorId"/>
    <ns5:parameter value="0.9592" type="Decimal" name="ExchgRate"/>
    <ns5:parameter value="USD" type="String" name="CurrencyCode"/>
    <ns5:parameter value="09/08/2011" type="String" name="MatDate"/>
</ns5:query>
</ns5:querySetRequest>

Есть идеи, что может вызвать излишний процессор для второго набора xml?

1 Ответ

0 голосов
/ 12 июля 2011

Это была проблема с чрезмерной регистрацией от SAXParser. Когда я установил ведение журнала, чтобы предупредить для соответствующих пакетов, он работал в миллисекундах. Сумасшедшие вещи!

...