I think that the issue only occurs with services that use parameter style WRAPPED and that have no @RequestWrapper annotation (or that have a @RequestWrapper annotation but that don't package the wrapper beans). I think that for WSDL-first, request wrappers are generated automatically, so this would only apply to services implemented using the code-first approach. Nevertheless this still covers a wide range of use cases, so that this is a problem.
Andreas On Sat, Dec 3, 2011 at 01:26, Sagara Gunathunga <sagara.gunathu...@gmail.com> wrote: > No. > > This is my method signature. > @WebService > @SOAPBinding(style = Style.DOCUMENT, use=Use.LITERAL) > public interface OrderService { > > @WebMethod > Order placeOrder(@WebParam(name="order")Order order); > > } > > Thanks ! > > On Fri, Dec 2, 2011 at 3:55 PM, Andreas Veithen <andreas.veit...@gmail.com> > wrote: >> >> Do your service methods have @RequestWrapper annotations? >> >> Andreas >> >> On Sat, Dec 3, 2011 at 00:31, Sagara Gunathunga >> <sagara.gunathu...@gmail.com> wrote: >> > I profiled a complex JAX-WS web service (refer the attachment) it seems >> > 45% >> > of time taken for JAXB unmarshalling while another 28.9% of time taken >> > for >> > message.getBodyBlockQNames() that eventually build the message through >> > AXIOM. I experimented hard coding some of the value calculation to avoid >> > this message building but what I realized is it's not a single place >> > JAX-WS >> > build this message instead when i avoid message building in a one place >> > it >> > build the message in a later stage. >> > >> > I can't realize why we have to build the message instead of passing it >> > to >> > JAXB Unmarshaller without building the message. >> > >> > >> > For me this seems like a extra cost , can any one explain the rational >> > behind this idea ? or can't we git rid of this message building. >> > >> > Thanks ! >> > >> > On Wed, Nov 30, 2011 at 5:27 AM, Isuru Suriarachchi <isur...@gmail.com> >> > wrote: >> >> >> >> Hi Charith, >> >> >> >> +1 for putting some more effort on improving our JAX-WS support. I'll >> >> commit the proper fix to [1] ASAP and that will remove the bottleneck >> >> in the >> >> JAX-WS MR. And also there'll be more places at which we can do >> >> improvements >> >> to gain even better performance numbers. >> >> >> >> Thanks, >> >> ~Isuru >> >> >> >> [1] https://issues.apache.org/jira/browse/AXIS2-4930 >> >> >> >> On Tue, Nov 29, 2011 at 4:51 PM, Charith Wickramarachchi >> >> <charith.dhanus...@gmail.com> wrote: >> >>> >> >>> Hi Devs , >> >>> >> >>> JAX-WS is becoming a popular key webservice development style. While >> >>> supporting its own web-service development/deployment style i think >> >>> Axis2 >> >>> should improve its JAX-WS implementation. I started to profile Axis2 >> >>> JAX-WS >> >>> implementation having performance improvement in mind and was able to >> >>> isolate a major bottleneck in this flow. (See the attached profile >> >>> image.) >> >>> Here the bottleneck was AXOM creating a XMLOutput factory per each >> >>> invocation due to a bug in JAXWSMessageReceiver. I submitted a fix for >> >>> this >> >>> in[1]. And we are currently in the process of discussing on a proper >> >>> solution for that issue. >> >>> >> >>> With this patch i was able to get ~75% performance improvement on >> >>> Simple >> >>> Echo jax-ws services and ~60% improvement with services with complex >> >>> types. >> >>> >> >>> >> >>> With this observation i think if we spend some energy on improving >> >>> Axis2 >> >>> JAX-WS performance we will be able to improve it a lot and >> >>> if we can publish that improved numbers may be with comparisons that >> >>> will >> >>> add a great value to this project. >> >>> >> >>> So i though of starting a discussion around it to discuss on how to >> >>> improve this and areas we must focus on. >> >>> >> >>> >> >>> [1]https://issues.apache.org/jira/browse/AXIS2-5203 >> >>> >> >>> thanks, >> >>> Charith >> >>> >> >>> -- >> >>> Charith Dhanushka Wickramarachchi >> >>> http://charithwiki.blogspot.com/ >> >>> >> >>> >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >> >>> For additional commands, e-mail: java-dev-h...@axis.apache.org >> >> >> >> >> >> >> >> >> >> -- >> >> Technical Lead, >> >> WSO2 Inc. http://wso2.org/ >> >> Blog : http://isurues.wordpress.com/ >> > >> > >> > >> > >> > -- >> > Sagara Gunathunga >> > >> > Blog - http://ssagara.blogspot.com >> > Web - http://people.apache.org/~sagara/ >> > LinkedIn - http://www.linkedin.com/in/ssagara >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >> > For additional commands, e-mail: java-dev-h...@axis.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >> For additional commands, e-mail: java-dev-h...@axis.apache.org >> > > > > -- > Sagara Gunathunga > > Blog - http://ssagara.blogspot.com > Web - http://people.apache.org/~sagara/ > LinkedIn - http://www.linkedin.com/in/ssagara --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org For additional commands, e-mail: java-dev-h...@axis.apache.org