Announcement Announcement Module
Collapse
No announcement yet.
Problems with AxiomSoapMessageFactory Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problems with AxiomSoapMessageFactory

    Hi,
    I have a performance problem with large Soap requests. Frequently the requests that my service has to process are 300 to 500k. At this time using org.springframework.ws.soap.saaj.SaajSoapMessageFa ctory it locks up the server for a long time with the CPU load at 100%.

    Reading the reference documentation I found out that I should rather use AxiomSoapMessageFactory, because it is based on the streaming axis API und does not need to keep the whole file in memory. Trying that I ran into errors. First I ran into a situation where my soap responses where no longer well formed XML, because they contained garbage, ie. the namespace attribute was broken. The responses looked like this:
    Code:
    ...<axis2ns6:GetBuildsFromProfileWithComponentResponse xmlns:axis2ns6="http://xedoc.corp.eboda.com/xedoc/schemas" ="http://xedoc.corp.eboda.com/xedoc/schemas" ...
    That was the result of including these components:
    Code:
        	<dependency>
        		<groupId>ws-commons</groupId>
        		<artifactId>axiom</artifactId>
        		<version>1.1</version>
        	</dependency>
        	<dependency>
        		<groupId>org.apache.ws.commons.axiom</groupId>
        		<artifactId>axiom-api</artifactId>
        		<version>1.2.5</version>
        	</dependency>
        	<dependency>
        		<groupId>javax.xml.stream</groupId>
        		<artifactId>stax-api</artifactId>
        		<version>1.0.1</version>
        	</dependency>
        	<dependency>
        		<groupId>stax</groupId>
        		<artifactId>stax</artifactId>
        		<version>1.2.0</version>
        	</dependency>
    I tried to tweak the versions and now I'm using
    Code:
     <dependency>
          <groupId>org.apache.ws.commons.axiom</groupId>
          <artifactId>axiom-api</artifactId>
          <version>1.2.5</version>
        </dependency>
        <dependency>
          <groupId>javax.xml.stream</groupId>
          <artifactId>stax-api</artifactId>
          <version>1.0.1</version>
        </dependency>
        <dependency>
          <groupId>stax</groupId>
          <artifactId>stax</artifactId>
          <version>1.2.0</version>
        </dependency>
        <dependency>
          <groupId>org.apache.ws.commons.axiom</groupId>
          <artifactId>axiom-impl</artifactId>
          <version>1.2.5</version>
        </dependency>
    I now get s different error on the service side:
    Code:
    2008-02-28 16:25:56,084 DEBUG [org.springframework.ws.soap.server.SoapMessageDispatcher] - Testing endpoint adapter [org.springframework.ws.server.endpoint.adapter.XPathParamAnnotationMethodEndpointAdapter@d75ffe]
    ERROR:  'Local name may not be null or empty'
    2008-02-28 16:25:57,839 DEBUG [org.springframework.ws.soap.server.SoapMessageDispatcher] - Testing endpoint exception resolver [org.springframework.ws.soap.server.endpoint.SoapFaultAnnotationExceptionResolver@d43c07]
    2008-02-28 16:25:57,839 DEBUG [org.springframework.ws.soap.server.SoapMessageDispatcher] - Testing endpoint exception resolver [org.springframework.ws.soap.server.endpoint.SoapFaultMappingExceptionResolver@51c208]
    2008-02-28 16:25:57,855 WARN [org.springframework.ws.soap.server.SoapMessageDispatcher] - Endpoint invocation resulted in exception - responding with SOAP Fault
    javax.xml.transform.TransformerException: java.lang.IllegalArgumentException: Local name may not be null or empty
    	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:670)
    	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:300)
    Currently I'm using endpoints of type:
    Code:
    org.springframework.ws.server.endpoint.annotation.Endpoint;
    Thanks for help with this problem.

  • #2
    To make my questions clearer:
    -What components of axiom and stax do work together?

    -How do I have to define my endpoints to best benefit of using the Axiom based WebServiceMessageFactory?

    Comment


    • #3
      Offhand I'm not sure why you get those errors.

      It might be because you're using the reference impl of stax from sun, and I think spring-ws requires the woodstox stax impl.

      Assuming you're using spring-ws 1.0.3, you should be able to see the full list of dependencies at http://mvnrepository.com/artifact/or...-ws-core/1.0.3.

      Of relevance are probably:

      org.apache.ws.commons.axiom axiom-api 1.2.5
      org.apache.ws.commons.axiom axiom-impl 1.2.5
      org.codehaus.woodstox wstx-asl 3.2.4
      stax stax-api 1.0.1

      Comment


      • #4
        BTW - Axiom is definitely the way to go with the large messages. Be sure you disable payload caching when you setup the axiom msg factory.

        On the server-side axiom will nicely stream the large messages on the requests - so you should be good. Responses do currently get parsed into an dom-like tree on the way out even with Axiom, but I'm hoping to propose a change soon that will prevent the dom-like tree of responses.

        Comment


        • #5
          Thanks Jim,

          I have tried the config you suggested, but it didn't really solve my problem, when using
          Code:
          		<dependency>
          			<groupId>org.apache.ws.commons.axiom</groupId>
          			<artifactId>axiom-api</artifactId>
          			<version>1.2.5</version>
          		</dependency>
          		<dependency>
          			<groupId>javax.xml.stream</groupId>
          			<artifactId>stax-api</artifactId>
          			<version>1.0.1</version>
          		</dependency>
          		<dependency>
          			<groupId>org.codehaus.woodstox</groupId>
          			<artifactId>wstx-asl</artifactId>
          			<version>3.2.4</version>
          		</dependency>
          		<dependency>
          			<groupId>org.apache.ws.commons.axiom</groupId>
          			<artifactId>axiom-impl</artifactId>
          			<version>1.2.5</version>
          		</dependency>
          I can reproduce the error I was seeing when using

          Code:
             <dependency>
                <groupId>stax</groupId>
                <artifactId>stax</artifactId>
                <version>1.2.0</version>
              </dependency>
          instead of
          Code:
          		<dependency>
          			<groupId>org.codehaus.woodstox</groupId>
          			<artifactId>wstx-asl</artifactId>
          			<version>3.2.4</version>
          		</dependency>
          That is

          Code:
          ERROR:  'Local name may not be null or empty'
          2008-02-29 18:51:31,136 DEBUG [org.springframework.ws.soap.server.SoapMessageDispatcher] - Testing endpoint exception resolver [org.springframework.ws.soap.server.endpoint.SoapFaultAnnotationExceptionResolver@3ac321]
          2008-02-29 18:51:31,137 DEBUG [org.springframework.ws.soap.server.SoapMessageDispatcher] - Testing endpoint exception resolver [org.springframework.ws.soap.server.endpoint.SoapFaultMappingExceptionResolver@8367ab]
          2008-02-29 18:51:31,151 WARN [org.springframework.ws.soap.server.SoapMessageDispatcher] - Endpoint invocation resulted in exception - responding with SOAP Fault
          javax.xml.transform.TransformerException: java.lang.IllegalArgumentException: Local name may not be null or empty
          	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:670)
          	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:300)
          	at org.springframework.xml.transform.TransformerObjectSupport.transform(TransformerObjectSupport.java:72)
          	at org.springframework.ws.server.endpoint.adapter.XPathParamAnnotationMethodEndpointAdapter.invokeInternal(XPathParamAnnotationMethodEndpointAdapter.java:115)
          	at org.springframework.ws.server.endpoint.adapter.AbstractMethodEndpointAdapter.invoke(AbstractMethodEndpointAdapter.java:58)
          	at org.springframework.ws.server.MessageDispatcher.dispatch(MessageDispatcher.java:215)
          	at org.springframework.ws.server.MessageDispatcher.receive(MessageDispatcher.java:162)
          	at org.springframework.ws.transport.support.WebServiceMessageReceiverObjectSupport.handleConnection(WebServiceMessageReceiverObjectSupport.java:87)
          	at org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter.handle(WebServiceMessageReceiverHandlerAdapter.java:57)
          	at org.springframework.ws.transport.http.MessageDispatcherServlet.doService(MessageDispatcherServlet.java:197)
          	at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:476)
          	at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:441)
          	at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
          	at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
          	at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
          	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
          	at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
          	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
          	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
          	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
          	at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
          	at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
          	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
          	at org.mortbay.jetty.Server.handle(Server.java:295)
          	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:503)
          	at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:841)
          	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:639)
          	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:210)
          	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379)
          	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:361)
          	at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
          I also tried to use no payload caching but I get an error, I guess, because I'm using an annotation endpoint (somewhat expected):

          Code:
          <?xml version="1.0" encoding="http://schemas.xmlsoap.org/soap/envelope/"?>
          <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
              <soapenv:Body>
                  <soapenv:Fault>
                      <faultcode>soapenv:Client</faultcode>
                      <faultstring xml:lang="en">Validation error</faultstring>
                      <detail>
                          <spring-ws:ValidationError xmlns:spring-ws="http://springframework.org/spring-ws"
                              >problem accessing the parser. Parser already
                          accessed!</spring-ws:ValidationError>
                      </detail>
                  </soapenv:Fault>
              </soapenv:Body>
          </soapenv:Envelope>
          What type of endpoint should I use?

          Comment


          • #6
            couzteau - I've never used the XPath method annotations, so I'm not sure the cause of your error for sure, especially since it apparently worked when using saaj, albeit slow. Your failure seems to be during the processing of the response for what it's worth - it might be useful to verify that the response your endpoint is generating is correct.

            Looking at the XPathParamAnnotationMethodEndpointAdapter code though, it looks it builds the request into a DOM tree proper, so I kind of doubt the XPath method annotations are the way to go with large requests. I'm not sure what your endpoint needs to do, but I'd think a StAX payload endpoint would probably avoid the cpu (and likely memory) issues you're running into since it could process your large requests in more of a streaming fashion.

            Comment


            • #7
              Jim, Thanks for your help. I'll follow up on this issue later.

              Comment


              • #8
                problem solved, I did try these dependencies:
                org.apache.ws.commons.axiom axiom-api 1.2.5
                org.apache.ws.commons.axiom axiom-impl 1.2.5
                org.codehaus.woodstox wstx-asl 3.2.4
                stax stax-api 1.0.1

                it all works now. Thanks again

                Comment


                • #9
                  Hi

                  For my config Axiom created empty body, with WSS4JSecurityInterceptor. Please have a look at post http://forum.springsource.org/showth...APProcessingEx and provide your suggestions

                  Thanks

                  Comment

                  Working...
                  X