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

Reply via email to