XFire

Performance issue because of duplicate manespace declarations

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.2.1
  • Fix Version/s: 1.2.6
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

The size of the SOAP responses returned can increase to the point where it can affect performance. This is due to namespaces being declared multiple times when it is not necessary sometimes. For example, this is a portion of a response containing a long array of KeyValue from a service published using Glue:

<n3:KeyValue xsi:type="n3:KeyValue">

<key xsi:type="xsd:string">AC</key>

<value xsi:type="xsd:string">Antigua and Barbuda</value>

</n3:KeyValue>

<n3:KeyValue xsi:type="n3:KeyValue">

<key xsi:type="xsd:string">AE</key>

<value xsi:type="xsd:string">United Arab Emirates</value>

</n3:KeyValue>

The same service published with xfire would return:

<ns2:KeyValue xmlns:ns2="http://www.arcwebservices.com/v2006_1/com.esri.aws.dto/">

<key xmlns="http://www.arcwebservices.com/v2006_1/com.esri.aws.dto/">AC</key>

<value xmlns="http://www.arcwebservices.com/v2006_1/com.esri.aws.dto/">Antigua and Barbuda</value>

</ns2:KeyValue>

<ns2:KeyValue xmlns:ns2="http://www.arcwebservices.com/v2006_1/com.esri.aws.dto/">

<key xmlns="http://www.arcwebservices.com/v2006_1/com.esri.aws.dto/">AE</key>

<value xmlns="http://www.arcwebservices.com/v2006_1/com.esri.aws.dto/">United Arab Emirates</value>

</ns2:KeyValue>

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tom Hill added a comment -

Here's a forum post containing more information on this issue:
http://www.nabble.com/SOAP-response-contains-redundant-namespaces-t3084484.html

We're noticing the redundant namespaces when using Aegis bindings with the latest versions of XFire, Stax API, and Woodstox, on top of Java 1.4.2 in Sun AppServer 7.

Our company is using XFire for web services that receive over a million hits a day, so the bandwidth used by the redundant namespaces in SOAP responses is very significant. We appreciate any help you can give on the issue, Dan.

Show
Tom Hill added a comment - Here's a forum post containing more information on this issue: http://www.nabble.com/SOAP-response-contains-redundant-namespaces-t3084484.html We're noticing the redundant namespaces when using Aegis bindings with the latest versions of XFire, Stax API, and Woodstox, on top of Java 1.4.2 in Sun AppServer 7. Our company is using XFire for web services that receive over a million hits a day, so the bandwidth used by the redundant namespaces in SOAP responses is very significant. We appreciate any help you can give on the issue, Dan.
Hide
Permalink
Jörg Wendland added a comment -

Hi,
the attached patch fixes this issue for us.

Jörg

Show
Jörg Wendland added a comment - Hi, the attached patch fixes this issue for us. Jörg
Hide
Permalink
Jörg Wendland added a comment -

Repeating my comment here
This patch fixes the issue for us.

Cheers,
Jörg

Show
Jörg Wendland added a comment - Repeating my comment here This patch fixes the issue for us. Cheers, Jörg
Hide
Permalink
Dan Diephouse added a comment -

Thanks for the patch! Will apply it shortly.

Show
Dan Diephouse added a comment - Thanks for the patch! Will apply it shortly.
Hide
Permalink
Dan Diephouse added a comment -

Unfortunately that does seem to break things in some cases and cause the wrong namespace to be written in some tests. Does changing line 107 in ElementWriter to this work for you?

else if (prefix == null || "".equals(decPrefix))

Show
Dan Diephouse added a comment - Unfortunately that does seem to break things in some cases and cause the wrong namespace to be written in some tests. Does changing line 107 in ElementWriter to this work for you? else if (prefix == null || "".equals(decPrefix))
Hide
Permalink
Jörg Wendland added a comment -

Nope, this doesn't fix it. I came to my solution by adding debug code that
showed this.prefix being the empty string most of the time. Maybe the
correct solution to this problem is a missing reset of this.prefix to null
somewhere in the code. I'll try and find this...

Show
Jörg Wendland added a comment - Nope, this doesn't fix it. I came to my solution by adding debug code that showed this.prefix being the empty string most of the time. Maybe the correct solution to this problem is a missing reset of this.prefix to null somewhere in the code. I'll try and find this...
Hide
Permalink
Dan Diephouse added a comment -

OK, please let me know what you come up with.

If you want to look at a failing test, check out the "DocumentAutoTypeTest".

Show
Dan Diephouse added a comment - OK, please let me know what you come up with. If you want to look at a failing test, check out the "DocumentAutoTypeTest".
Hide
Permalink
Tomasz Sztelak added a comment -

fixed in svn

Show
Tomasz Sztelak added a comment - fixed in svn
Hide
Permalink
Emmanuel Servent added a comment -

Hi,

In my configuration, I always see the redundant namespace in attributes.

I'm using the latest release of Xfire (1.2.6), Stax (1.2.0).
I'm using Spring (1.2.8) to configure XFire.
The AppServer is Weblogic Server 8.1 SP4 with JDK-1.4.2_12.

What can I do to resolve this heavy problem?

Thank you.

SOAP message:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<ns1:getListClientsResponse xmlns:ns1="http://services.myapp.fr">
<ns1:out>
<ns1:Client>
<IDClient xmlns="http://services.myapp.fr">1000123456</IDClient>
</ns1:Client>
</ns1:out>
</ns1:getListClientsResponse>
</soap:Body>
</soap:Envelope>

Show
Emmanuel Servent added a comment - Hi, In my configuration, I always see the redundant namespace in attributes. I'm using the latest release of Xfire (1.2.6), Stax (1.2.0). I'm using Spring (1.2.8) to configure XFire. The AppServer is Weblogic Server 8.1 SP4 with JDK-1.4.2_12. What can I do to resolve this heavy problem? Thank you. SOAP message: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <ns1:getListClientsResponse xmlns:ns1="http://services.myapp.fr"> <ns1:out> <ns1:Client> <IDClient xmlns="http://services.myapp.fr">1000123456</IDClient> </ns1:Client> </ns1:out> </ns1:getListClientsResponse> </soap:Body> </soap:Envelope>
Hide
Permalink
Jessica J added a comment -

I have tried the patch, with no success.

I am using Spring Version 1.2.8, and XFire Version 1.2.6.

This problem results in a HUGE performance hit. Will any additional investigation be done on it, now that CXF is in place?

Show
Jessica J added a comment - I have tried the patch, with no success. I am using Spring Version 1.2.8, and XFire Version 1.2.6. This problem results in a HUGE performance hit. Will any additional investigation be done on it, now that CXF is in place?

People

  • Assignee:
    Tomasz Sztelak
    Reporter:
    Tawfik Lachheb
Vote (9)
Watch (7)

Dates

  • Created:
    Updated:
    Resolved: