You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jorg Heymans <jo...@gmail.com> on 2015/10/01 08:44:31 UTC
ReflectionServiceFactoryBean performance
Hi,
We have about 15 jaxws client definitions in our application context
defined like this :
<jaxws:client id="myService" serviceClass="my.service.Service"
address="http://....."/>
Initializing all of these during startup takes on average about 2.5 to 3
minutes. This is already after
adding -Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true , before
that it was more like 5-6 minutes.
Is there a way to improve this ? We are going to add more services as the
application grows, and already now this cxf init takes up more than half of
our deployment time.
Thanks,
Jorg Heymans
Re: ReflectionServiceFactoryBean performance
Posted by Jorg Heymans <jo...@gmail.com>.
OK 1) i can easily solve but 2) means changing the way the model is
generated that is too much of a risk for me. I will just leave it as is
then.
Thanks anyway for your help !
Jorg
On Thu, Oct 8, 2015 at 1:53 PM Daniel Kulp <dk...@apache.org> wrote:
>
> OH…. Two issues:
>
> 1) I don’t think the data binding object itself can be a singleton, just
> the context it holds onto.
>
> 2) The error implies that you don’t have ALL the classes that are needed.
> For JAXWS, we internally (via ASM) will create the wrapper classes for the
> doc/lit wrapped messages if there are not classes for them. That’s likely
> why it was ending up with new JAXB contexts for each with the previous
> setup as well.
>
> I would suggest running a java2wsdl on the classes with the -wrapperbean
> flag to have it generate those wrappers. You may then need to add
> @RequestWrapper and @ResponseWrappper annotations to point to the right
> classes.
>
>
> Dan
>
>
>
>
> > On Oct 8, 2015, at 2:04 AM, Jorg Heymans <jo...@gmail.com> wrote:
> >
> > Tried this, got exception during startup :
> >
> > Caused By: org.apache.cxf.service.factory.ServiceConstructionException:
> > Service class my.ProgrammeService method getProgramme part {
> > http://my/service/programme/v0}parameters cannot be mapped to schema.
> Check
> > for use of a JAX-WS-specific type without the JAX-WS service factory
> bean.
> > at
> >
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createBareMessage(ReflectionServiceFactoryBean.java:1227)
> > [INFO] [talledLocalContainer] at
> >
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:477)
> > [INFO] [talledLocalContainer] at
> >
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:712)
> > [INFO] [talledLocalContainer] at
> >
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527)
> > [INFO] [talledLocalContainer] at
> >
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:261)
> >
> > Config:
> >
> > <bean id="singletonJAXBDataBinding"
> class="my.SingletonJAXBDataBinding"/>
> >
> > <jaxws:client serviceClass="my.ProgrammeService" address="http://
> > ${loadbalancer}/service/programme/v0">
> > <jaxws:dataBinding>
> > <ref bean="singletonJAXBDataBinding"/>
> > </jaxws:dataBinding>
> > </jaxws:client>
> >
> > Presumably the jaxb context i have init'ed myself is not quite what cxf
> is
> > expecting ?
> >
> > Jorg
> >
> >
> >
> > On Wed, Oct 7, 2015 at 6:30 PM Daniel Kulp <dk...@apache.org> wrote:
> >
> >>
> >>> On Oct 7, 2015, at 9:42 AM, Jorg Heymans <jo...@gmail.com>
> wrote:
> >>>
> >>> The only thing i could easily try was option 2, but it did not make a
> >>> difference. We have about 6-700 entities in our schema divided over
> >> several
> >>> hundreds of packages. All of this is put in the same jaxbcontext.
> >>>
> >>> Enabling jaxb logging reveals that the context is indeed recreated for
> >> each
> >>> service (i.e. each definition of jaxws:client), and given the amount of
> >>> entities and packages it just adds up tremendously. For example jaxb
> >> seems
> >>> to search for jaxb.properties in every single package present in the
> >>> context. We see a big difference though on local deployment using fast
> >>> windows SSD machines and server side deployments on virtualized
> >>> infrastructure, on the former it is more bearable about 45 seconds.
> >>>
> >>> Also, for other application purposes i am myself already constructing
> the
> >>> jaxbcontext as a singleton. Could i not make cxf reuse that one somehow
> >> ? I
> >>> looked at JAXBContextCache but it's not so clear how i would go about
> >>> initializing it with an existing context.
> >>
> >> One option would be to subclass org.apache.cxf.jaxb.JAXBDataBinding and
> >> override the
> >>
> >> public CachedContextAndSchemas createJAXBContextAndSchemas(Set<Class<?>>
> >> classes,
> >> String
> >> defaultNs);
> >>
> >> method. The CachedContextAndSchemas object that is returned could be a
> >> singleton for your application that contains your global JAXBContext.
> >>
> >> In the spring config, you can do:
> >>
> >> <jaxws:client …..>
> >> <jaxws:dataBinding>
> >> <bean class=“org.foo.MyJAXBDataBinding”>
> >> ;;; inject whatever you need in here
> >> </bean>
> >> </jaxws:dataBinding>
> >> </jaxws:client>
> >>
> >>
> >>
> >> Dan
> >>
> >>
> >>>
> >>> Jorg
> >>>
> >>>
> >>>
> >>> On Tue, Oct 6, 2015 at 3:58 PM Daniel Kulp <dk...@apache.org> wrote:
> >>>
> >>>>
> >>>>> On Oct 5, 2015, at 6:12 AM, Jorg Heymans <jo...@gmail.com>
> >> wrote:
> >>>>> It seems that jaxb context init is still the culprit. We use the
> >>>>> com.sun.xml.bind.v2.ContextFactory , switching for example to the
> >>>>> Eclipselink implementation
> >>>>> (org.eclipse.persistence.jaxb.JAXBContextFactory) was even slower.
> >>>> Spring's
> >>>>> lazy init is no good here, makes me wonder if cxf could do a 'true'
> >> lazy
> >>>>> init and defer this expensive init of the service until actual
> methods
> >>>> are
> >>>>> called on it. Feasible ?
> >>>>
> >>>> Not really, no. We need the information from the context to check to
> >>>> make sure the methods on the clients are even valid.
> >>>>
> >>>> It’s possible that 15 clients are creating 15 unique JAXB Contexts.
> >> One
> >>>> thing you could TRY is collect ALL the classes that are used by all 15
> >>>> clients and do one of:
> >>>>
> >>>> 1) Add @XmlSeeAlso annotations or similar to pull in all the classes
> >>>>
> >>>> 2) Use the “jaxb.additionalContextClasses” property to provide a list
> of
> >>>> all the classes
> >>>> <jaxws:properties>
> >>>> <entry key="jaxb.additionalContextClasses">
> >>>> <bean
> >>>> class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
> >>>> <property name="classNames">
> >>>> <list>
> >>>>
> >>>> <value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</value>
> >>>> </list>
> >>>> </property>
> >>>> </bean>
> >>>> </entry>
> >>>> </jaxws:properties>
> >>>>
> >>>> 3) Possibly create a list of all the classes and pre-initialize via
> the
> >>>> JAXBContextCache.getCachedContextAndSchemas method. I’m not 100%
> sure
> >>>> this will work.
> >>>>
> >>>>
> >>>> Basically, if you can get ONE large JAXBContext serving all the
> clients,
> >>>> it might be quicker than 15 smaller. Not really sure though.
> >>>>
> >>>> Dan
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Jorg
> >>>>>
> >>>>> On Mon, Oct 5, 2015 at 10:42 AM Jorg Heymans <jorg.heymans@gmail.com
> >
> >>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> The wsdlLocation attribute is not specified, and to be honest i have
> >> no
> >>>>>> idea if there is any remote downloading involved during startup. We
> >> just
> >>>>>> specify id and serviceClass attribute and let cxf do its thing. I
> will
> >>>>>> try to profile and report back.
> >>>>>>
> >>>>>> Jorg
> >>>>>>
> >>>>>> On Sun, Oct 4, 2015 at 5:23 PM Andrei Shakirin <
> ashakirin@talend.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> 2.5 to 3 minutes is quite long even for 15 clients initialization.
> >>>>>>> Did you specify wsdlLocation attribute in jaxws:client? Can
> >> performance
> >>>>>>> be related to remote WSDL downloading?
> >>>>>>> Could you bind any profiling tool and discover which operation
> caused
> >>>>>>> performance problem?
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Andrei.
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Jorg Heymans [mailto:jorg.heymans@gmail.com]
> >>>>>>>> Sent: Donnerstag, 1. Oktober 2015 08:45
> >>>>>>>> To: users@cxf.apache.org
> >>>>>>>> Subject: ReflectionServiceFactoryBean performance
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> We have about 15 jaxws client definitions in our application
> context
> >>>>>>> defined
> >>>>>>>> like this :
> >>>>>>>>
> >>>>>>>> <jaxws:client id="myService" serviceClass="my.service.Service"
> >>>>>>>> address="http://....."/>
> >>>>>>>>
> >>>>>>>> Initializing all of these during startup takes on average about
> 2.5
> >> to
> >>>>>>> 3 minutes.
> >>>>>>>> This is already after adding -
> >>>>>>>> Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true ,
> before
> >>>>>>> that it
> >>>>>>>> was more like 5-6 minutes.
> >>>>>>>>
> >>>>>>>> Is there a way to improve this ? We are going to add more services
> >> as
> >>>>>>> the
> >>>>>>>> application grows, and already now this cxf init takes up more
> than
> >>>>>>> half of our
> >>>>>>>> deployment time.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Jorg Heymans
> >>>>>>>
> >>>>>>
> >>>>
> >>>> --
> >>>> Daniel Kulp
> >>>> dkulp@apache.org - http://dankulp.com/blog
> >>>> Talend Community Coder - http://coders.talend.com
> >>>>
> >>>>
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: ReflectionServiceFactoryBean performance
Posted by Daniel Kulp <dk...@apache.org>.
OH…. Two issues:
1) I don’t think the data binding object itself can be a singleton, just the context it holds onto.
2) The error implies that you don’t have ALL the classes that are needed. For JAXWS, we internally (via ASM) will create the wrapper classes for the doc/lit wrapped messages if there are not classes for them. That’s likely why it was ending up with new JAXB contexts for each with the previous setup as well.
I would suggest running a java2wsdl on the classes with the -wrapperbean flag to have it generate those wrappers. You may then need to add @RequestWrapper and @ResponseWrappper annotations to point to the right classes.
Dan
> On Oct 8, 2015, at 2:04 AM, Jorg Heymans <jo...@gmail.com> wrote:
>
> Tried this, got exception during startup :
>
> Caused By: org.apache.cxf.service.factory.ServiceConstructionException:
> Service class my.ProgrammeService method getProgramme part {
> http://my/service/programme/v0}parameters cannot be mapped to schema. Check
> for use of a JAX-WS-specific type without the JAX-WS service factory bean.
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createBareMessage(ReflectionServiceFactoryBean.java:1227)
> [INFO] [talledLocalContainer] at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:477)
> [INFO] [talledLocalContainer] at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:712)
> [INFO] [talledLocalContainer] at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527)
> [INFO] [talledLocalContainer] at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:261)
>
> Config:
>
> <bean id="singletonJAXBDataBinding" class="my.SingletonJAXBDataBinding"/>
>
> <jaxws:client serviceClass="my.ProgrammeService" address="http://
> ${loadbalancer}/service/programme/v0">
> <jaxws:dataBinding>
> <ref bean="singletonJAXBDataBinding"/>
> </jaxws:dataBinding>
> </jaxws:client>
>
> Presumably the jaxb context i have init'ed myself is not quite what cxf is
> expecting ?
>
> Jorg
>
>
>
> On Wed, Oct 7, 2015 at 6:30 PM Daniel Kulp <dk...@apache.org> wrote:
>
>>
>>> On Oct 7, 2015, at 9:42 AM, Jorg Heymans <jo...@gmail.com> wrote:
>>>
>>> The only thing i could easily try was option 2, but it did not make a
>>> difference. We have about 6-700 entities in our schema divided over
>> several
>>> hundreds of packages. All of this is put in the same jaxbcontext.
>>>
>>> Enabling jaxb logging reveals that the context is indeed recreated for
>> each
>>> service (i.e. each definition of jaxws:client), and given the amount of
>>> entities and packages it just adds up tremendously. For example jaxb
>> seems
>>> to search for jaxb.properties in every single package present in the
>>> context. We see a big difference though on local deployment using fast
>>> windows SSD machines and server side deployments on virtualized
>>> infrastructure, on the former it is more bearable about 45 seconds.
>>>
>>> Also, for other application purposes i am myself already constructing the
>>> jaxbcontext as a singleton. Could i not make cxf reuse that one somehow
>> ? I
>>> looked at JAXBContextCache but it's not so clear how i would go about
>>> initializing it with an existing context.
>>
>> One option would be to subclass org.apache.cxf.jaxb.JAXBDataBinding and
>> override the
>>
>> public CachedContextAndSchemas createJAXBContextAndSchemas(Set<Class<?>>
>> classes,
>> String
>> defaultNs);
>>
>> method. The CachedContextAndSchemas object that is returned could be a
>> singleton for your application that contains your global JAXBContext.
>>
>> In the spring config, you can do:
>>
>> <jaxws:client …..>
>> <jaxws:dataBinding>
>> <bean class=“org.foo.MyJAXBDataBinding”>
>> ;;; inject whatever you need in here
>> </bean>
>> </jaxws:dataBinding>
>> </jaxws:client>
>>
>>
>>
>> Dan
>>
>>
>>>
>>> Jorg
>>>
>>>
>>>
>>> On Tue, Oct 6, 2015 at 3:58 PM Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>>
>>>>> On Oct 5, 2015, at 6:12 AM, Jorg Heymans <jo...@gmail.com>
>> wrote:
>>>>> It seems that jaxb context init is still the culprit. We use the
>>>>> com.sun.xml.bind.v2.ContextFactory , switching for example to the
>>>>> Eclipselink implementation
>>>>> (org.eclipse.persistence.jaxb.JAXBContextFactory) was even slower.
>>>> Spring's
>>>>> lazy init is no good here, makes me wonder if cxf could do a 'true'
>> lazy
>>>>> init and defer this expensive init of the service until actual methods
>>>> are
>>>>> called on it. Feasible ?
>>>>
>>>> Not really, no. We need the information from the context to check to
>>>> make sure the methods on the clients are even valid.
>>>>
>>>> It’s possible that 15 clients are creating 15 unique JAXB Contexts.
>> One
>>>> thing you could TRY is collect ALL the classes that are used by all 15
>>>> clients and do one of:
>>>>
>>>> 1) Add @XmlSeeAlso annotations or similar to pull in all the classes
>>>>
>>>> 2) Use the “jaxb.additionalContextClasses” property to provide a list of
>>>> all the classes
>>>> <jaxws:properties>
>>>> <entry key="jaxb.additionalContextClasses">
>>>> <bean
>>>> class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
>>>> <property name="classNames">
>>>> <list>
>>>>
>>>> <value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</value>
>>>> </list>
>>>> </property>
>>>> </bean>
>>>> </entry>
>>>> </jaxws:properties>
>>>>
>>>> 3) Possibly create a list of all the classes and pre-initialize via the
>>>> JAXBContextCache.getCachedContextAndSchemas method. I’m not 100% sure
>>>> this will work.
>>>>
>>>>
>>>> Basically, if you can get ONE large JAXBContext serving all the clients,
>>>> it might be quicker than 15 smaller. Not really sure though.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>>
>>>>> Jorg
>>>>>
>>>>> On Mon, Oct 5, 2015 at 10:42 AM Jorg Heymans <jo...@gmail.com>
>>>> wrote:
>>>>>
>>>>>>
>>>>>> The wsdlLocation attribute is not specified, and to be honest i have
>> no
>>>>>> idea if there is any remote downloading involved during startup. We
>> just
>>>>>> specify id and serviceClass attribute and let cxf do its thing. I will
>>>>>> try to profile and report back.
>>>>>>
>>>>>> Jorg
>>>>>>
>>>>>> On Sun, Oct 4, 2015 at 5:23 PM Andrei Shakirin <as...@talend.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> 2.5 to 3 minutes is quite long even for 15 clients initialization.
>>>>>>> Did you specify wsdlLocation attribute in jaxws:client? Can
>> performance
>>>>>>> be related to remote WSDL downloading?
>>>>>>> Could you bind any profiling tool and discover which operation caused
>>>>>>> performance problem?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Andrei.
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jorg Heymans [mailto:jorg.heymans@gmail.com]
>>>>>>>> Sent: Donnerstag, 1. Oktober 2015 08:45
>>>>>>>> To: users@cxf.apache.org
>>>>>>>> Subject: ReflectionServiceFactoryBean performance
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We have about 15 jaxws client definitions in our application context
>>>>>>> defined
>>>>>>>> like this :
>>>>>>>>
>>>>>>>> <jaxws:client id="myService" serviceClass="my.service.Service"
>>>>>>>> address="http://....."/>
>>>>>>>>
>>>>>>>> Initializing all of these during startup takes on average about 2.5
>> to
>>>>>>> 3 minutes.
>>>>>>>> This is already after adding -
>>>>>>>> Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true , before
>>>>>>> that it
>>>>>>>> was more like 5-6 minutes.
>>>>>>>>
>>>>>>>> Is there a way to improve this ? We are going to add more services
>> as
>>>>>>> the
>>>>>>>> application grows, and already now this cxf init takes up more than
>>>>>>> half of our
>>>>>>>> deployment time.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jorg Heymans
>>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: ReflectionServiceFactoryBean performance
Posted by Jorg Heymans <jo...@gmail.com>.
Tried this, got exception during startup :
Caused By: org.apache.cxf.service.factory.ServiceConstructionException:
Service class my.ProgrammeService method getProgramme part {
http://my/service/programme/v0}parameters cannot be mapped to schema. Check
for use of a JAX-WS-specific type without the JAX-WS service factory bean.
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createBareMessage(ReflectionServiceFactoryBean.java:1227)
[INFO] [talledLocalContainer] at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:477)
[INFO] [talledLocalContainer] at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:712)
[INFO] [talledLocalContainer] at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527)
[INFO] [talledLocalContainer] at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:261)
Config:
<bean id="singletonJAXBDataBinding" class="my.SingletonJAXBDataBinding"/>
<jaxws:client serviceClass="my.ProgrammeService" address="http://
${loadbalancer}/service/programme/v0">
<jaxws:dataBinding>
<ref bean="singletonJAXBDataBinding"/>
</jaxws:dataBinding>
</jaxws:client>
Presumably the jaxb context i have init'ed myself is not quite what cxf is
expecting ?
Jorg
On Wed, Oct 7, 2015 at 6:30 PM Daniel Kulp <dk...@apache.org> wrote:
>
> > On Oct 7, 2015, at 9:42 AM, Jorg Heymans <jo...@gmail.com> wrote:
> >
> > The only thing i could easily try was option 2, but it did not make a
> > difference. We have about 6-700 entities in our schema divided over
> several
> > hundreds of packages. All of this is put in the same jaxbcontext.
> >
> > Enabling jaxb logging reveals that the context is indeed recreated for
> each
> > service (i.e. each definition of jaxws:client), and given the amount of
> > entities and packages it just adds up tremendously. For example jaxb
> seems
> > to search for jaxb.properties in every single package present in the
> > context. We see a big difference though on local deployment using fast
> > windows SSD machines and server side deployments on virtualized
> > infrastructure, on the former it is more bearable about 45 seconds.
> >
> > Also, for other application purposes i am myself already constructing the
> > jaxbcontext as a singleton. Could i not make cxf reuse that one somehow
> ? I
> > looked at JAXBContextCache but it's not so clear how i would go about
> > initializing it with an existing context.
>
> One option would be to subclass org.apache.cxf.jaxb.JAXBDataBinding and
> override the
>
> public CachedContextAndSchemas createJAXBContextAndSchemas(Set<Class<?>>
> classes,
> String
> defaultNs);
>
> method. The CachedContextAndSchemas object that is returned could be a
> singleton for your application that contains your global JAXBContext.
>
> In the spring config, you can do:
>
> <jaxws:client …..>
> <jaxws:dataBinding>
> <bean class=“org.foo.MyJAXBDataBinding”>
> ;;; inject whatever you need in here
> </bean>
> </jaxws:dataBinding>
> </jaxws:client>
>
>
>
> Dan
>
>
> >
> > Jorg
> >
> >
> >
> > On Tue, Oct 6, 2015 at 3:58 PM Daniel Kulp <dk...@apache.org> wrote:
> >
> >>
> >>> On Oct 5, 2015, at 6:12 AM, Jorg Heymans <jo...@gmail.com>
> wrote:
> >>> It seems that jaxb context init is still the culprit. We use the
> >>> com.sun.xml.bind.v2.ContextFactory , switching for example to the
> >>> Eclipselink implementation
> >>> (org.eclipse.persistence.jaxb.JAXBContextFactory) was even slower.
> >> Spring's
> >>> lazy init is no good here, makes me wonder if cxf could do a 'true'
> lazy
> >>> init and defer this expensive init of the service until actual methods
> >> are
> >>> called on it. Feasible ?
> >>
> >> Not really, no. We need the information from the context to check to
> >> make sure the methods on the clients are even valid.
> >>
> >> It’s possible that 15 clients are creating 15 unique JAXB Contexts.
> One
> >> thing you could TRY is collect ALL the classes that are used by all 15
> >> clients and do one of:
> >>
> >> 1) Add @XmlSeeAlso annotations or similar to pull in all the classes
> >>
> >> 2) Use the “jaxb.additionalContextClasses” property to provide a list of
> >> all the classes
> >> <jaxws:properties>
> >> <entry key="jaxb.additionalContextClasses">
> >> <bean
> >> class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
> >> <property name="classNames">
> >> <list>
> >>
> >> <value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</value>
> >> </list>
> >> </property>
> >> </bean>
> >> </entry>
> >> </jaxws:properties>
> >>
> >> 3) Possibly create a list of all the classes and pre-initialize via the
> >> JAXBContextCache.getCachedContextAndSchemas method. I’m not 100% sure
> >> this will work.
> >>
> >>
> >> Basically, if you can get ONE large JAXBContext serving all the clients,
> >> it might be quicker than 15 smaller. Not really sure though.
> >>
> >> Dan
> >>
> >>
> >>
> >>>
> >>> Jorg
> >>>
> >>> On Mon, Oct 5, 2015 at 10:42 AM Jorg Heymans <jo...@gmail.com>
> >> wrote:
> >>>
> >>>>
> >>>> The wsdlLocation attribute is not specified, and to be honest i have
> no
> >>>> idea if there is any remote downloading involved during startup. We
> just
> >>>> specify id and serviceClass attribute and let cxf do its thing. I will
> >>>> try to profile and report back.
> >>>>
> >>>> Jorg
> >>>>
> >>>> On Sun, Oct 4, 2015 at 5:23 PM Andrei Shakirin <as...@talend.com>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> 2.5 to 3 minutes is quite long even for 15 clients initialization.
> >>>>> Did you specify wsdlLocation attribute in jaxws:client? Can
> performance
> >>>>> be related to remote WSDL downloading?
> >>>>> Could you bind any profiling tool and discover which operation caused
> >>>>> performance problem?
> >>>>>
> >>>>> Regards,
> >>>>> Andrei.
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Jorg Heymans [mailto:jorg.heymans@gmail.com]
> >>>>>> Sent: Donnerstag, 1. Oktober 2015 08:45
> >>>>>> To: users@cxf.apache.org
> >>>>>> Subject: ReflectionServiceFactoryBean performance
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> We have about 15 jaxws client definitions in our application context
> >>>>> defined
> >>>>>> like this :
> >>>>>>
> >>>>>> <jaxws:client id="myService" serviceClass="my.service.Service"
> >>>>>> address="http://....."/>
> >>>>>>
> >>>>>> Initializing all of these during startup takes on average about 2.5
> to
> >>>>> 3 minutes.
> >>>>>> This is already after adding -
> >>>>>> Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true , before
> >>>>> that it
> >>>>>> was more like 5-6 minutes.
> >>>>>>
> >>>>>> Is there a way to improve this ? We are going to add more services
> as
> >>>>> the
> >>>>>> application grows, and already now this cxf init takes up more than
> >>>>> half of our
> >>>>>> deployment time.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Jorg Heymans
> >>>>>
> >>>>
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: ReflectionServiceFactoryBean performance
Posted by Daniel Kulp <dk...@apache.org>.
> On Oct 7, 2015, at 9:42 AM, Jorg Heymans <jo...@gmail.com> wrote:
>
> The only thing i could easily try was option 2, but it did not make a
> difference. We have about 6-700 entities in our schema divided over several
> hundreds of packages. All of this is put in the same jaxbcontext.
>
> Enabling jaxb logging reveals that the context is indeed recreated for each
> service (i.e. each definition of jaxws:client), and given the amount of
> entities and packages it just adds up tremendously. For example jaxb seems
> to search for jaxb.properties in every single package present in the
> context. We see a big difference though on local deployment using fast
> windows SSD machines and server side deployments on virtualized
> infrastructure, on the former it is more bearable about 45 seconds.
>
> Also, for other application purposes i am myself already constructing the
> jaxbcontext as a singleton. Could i not make cxf reuse that one somehow ? I
> looked at JAXBContextCache but it's not so clear how i would go about
> initializing it with an existing context.
One option would be to subclass org.apache.cxf.jaxb.JAXBDataBinding and override the
public CachedContextAndSchemas createJAXBContextAndSchemas(Set<Class<?>> classes,
String defaultNs);
method. The CachedContextAndSchemas object that is returned could be a singleton for your application that contains your global JAXBContext.
In the spring config, you can do:
<jaxws:client …..>
<jaxws:dataBinding>
<bean class=“org.foo.MyJAXBDataBinding”>
;;; inject whatever you need in here
</bean>
</jaxws:dataBinding>
</jaxws:client>
Dan
>
> Jorg
>
>
>
> On Tue, Oct 6, 2015 at 3:58 PM Daniel Kulp <dk...@apache.org> wrote:
>
>>
>>> On Oct 5, 2015, at 6:12 AM, Jorg Heymans <jo...@gmail.com> wrote:
>>> It seems that jaxb context init is still the culprit. We use the
>>> com.sun.xml.bind.v2.ContextFactory , switching for example to the
>>> Eclipselink implementation
>>> (org.eclipse.persistence.jaxb.JAXBContextFactory) was even slower.
>> Spring's
>>> lazy init is no good here, makes me wonder if cxf could do a 'true' lazy
>>> init and defer this expensive init of the service until actual methods
>> are
>>> called on it. Feasible ?
>>
>> Not really, no. We need the information from the context to check to
>> make sure the methods on the clients are even valid.
>>
>> It’s possible that 15 clients are creating 15 unique JAXB Contexts. One
>> thing you could TRY is collect ALL the classes that are used by all 15
>> clients and do one of:
>>
>> 1) Add @XmlSeeAlso annotations or similar to pull in all the classes
>>
>> 2) Use the “jaxb.additionalContextClasses” property to provide a list of
>> all the classes
>> <jaxws:properties>
>> <entry key="jaxb.additionalContextClasses">
>> <bean
>> class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
>> <property name="classNames">
>> <list>
>>
>> <value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</value>
>> </list>
>> </property>
>> </bean>
>> </entry>
>> </jaxws:properties>
>>
>> 3) Possibly create a list of all the classes and pre-initialize via the
>> JAXBContextCache.getCachedContextAndSchemas method. I’m not 100% sure
>> this will work.
>>
>>
>> Basically, if you can get ONE large JAXBContext serving all the clients,
>> it might be quicker than 15 smaller. Not really sure though.
>>
>> Dan
>>
>>
>>
>>>
>>> Jorg
>>>
>>> On Mon, Oct 5, 2015 at 10:42 AM Jorg Heymans <jo...@gmail.com>
>> wrote:
>>>
>>>>
>>>> The wsdlLocation attribute is not specified, and to be honest i have no
>>>> idea if there is any remote downloading involved during startup. We just
>>>> specify id and serviceClass attribute and let cxf do its thing. I will
>>>> try to profile and report back.
>>>>
>>>> Jorg
>>>>
>>>> On Sun, Oct 4, 2015 at 5:23 PM Andrei Shakirin <as...@talend.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> 2.5 to 3 minutes is quite long even for 15 clients initialization.
>>>>> Did you specify wsdlLocation attribute in jaxws:client? Can performance
>>>>> be related to remote WSDL downloading?
>>>>> Could you bind any profiling tool and discover which operation caused
>>>>> performance problem?
>>>>>
>>>>> Regards,
>>>>> Andrei.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jorg Heymans [mailto:jorg.heymans@gmail.com]
>>>>>> Sent: Donnerstag, 1. Oktober 2015 08:45
>>>>>> To: users@cxf.apache.org
>>>>>> Subject: ReflectionServiceFactoryBean performance
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We have about 15 jaxws client definitions in our application context
>>>>> defined
>>>>>> like this :
>>>>>>
>>>>>> <jaxws:client id="myService" serviceClass="my.service.Service"
>>>>>> address="http://....."/>
>>>>>>
>>>>>> Initializing all of these during startup takes on average about 2.5 to
>>>>> 3 minutes.
>>>>>> This is already after adding -
>>>>>> Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true , before
>>>>> that it
>>>>>> was more like 5-6 minutes.
>>>>>>
>>>>>> Is there a way to improve this ? We are going to add more services as
>>>>> the
>>>>>> application grows, and already now this cxf init takes up more than
>>>>> half of our
>>>>>> deployment time.
>>>>>>
>>>>>> Thanks,
>>>>>> Jorg Heymans
>>>>>
>>>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: ReflectionServiceFactoryBean performance
Posted by Jorg Heymans <jo...@gmail.com>.
The only thing i could easily try was option 2, but it did not make a
difference. We have about 6-700 entities in our schema divided over several
hundreds of packages. All of this is put in the same jaxbcontext.
Enabling jaxb logging reveals that the context is indeed recreated for each
service (i.e. each definition of jaxws:client), and given the amount of
entities and packages it just adds up tremendously. For example jaxb seems
to search for jaxb.properties in every single package present in the
context. We see a big difference though on local deployment using fast
windows SSD machines and server side deployments on virtualized
infrastructure, on the former it is more bearable about 45 seconds.
Also, for other application purposes i am myself already constructing the
jaxbcontext as a singleton. Could i not make cxf reuse that one somehow ? I
looked at JAXBContextCache but it's not so clear how i would go about
initializing it with an existing context.
Jorg
On Tue, Oct 6, 2015 at 3:58 PM Daniel Kulp <dk...@apache.org> wrote:
>
> > On Oct 5, 2015, at 6:12 AM, Jorg Heymans <jo...@gmail.com> wrote:
> > It seems that jaxb context init is still the culprit. We use the
> > com.sun.xml.bind.v2.ContextFactory , switching for example to the
> > Eclipselink implementation
> > (org.eclipse.persistence.jaxb.JAXBContextFactory) was even slower.
> Spring's
> > lazy init is no good here, makes me wonder if cxf could do a 'true' lazy
> > init and defer this expensive init of the service until actual methods
> are
> > called on it. Feasible ?
>
> Not really, no. We need the information from the context to check to
> make sure the methods on the clients are even valid.
>
> It’s possible that 15 clients are creating 15 unique JAXB Contexts. One
> thing you could TRY is collect ALL the classes that are used by all 15
> clients and do one of:
>
> 1) Add @XmlSeeAlso annotations or similar to pull in all the classes
>
> 2) Use the “jaxb.additionalContextClasses” property to provide a list of
> all the classes
> <jaxws:properties>
> <entry key="jaxb.additionalContextClasses">
> <bean
> class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
> <property name="classNames">
> <list>
>
> <value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</value>
> </list>
> </property>
> </bean>
> </entry>
> </jaxws:properties>
>
> 3) Possibly create a list of all the classes and pre-initialize via the
> JAXBContextCache.getCachedContextAndSchemas method. I’m not 100% sure
> this will work.
>
>
> Basically, if you can get ONE large JAXBContext serving all the clients,
> it might be quicker than 15 smaller. Not really sure though.
>
> Dan
>
>
>
> >
> > Jorg
> >
> > On Mon, Oct 5, 2015 at 10:42 AM Jorg Heymans <jo...@gmail.com>
> wrote:
> >
> >>
> >> The wsdlLocation attribute is not specified, and to be honest i have no
> >> idea if there is any remote downloading involved during startup. We just
> >> specify id and serviceClass attribute and let cxf do its thing. I will
> >> try to profile and report back.
> >>
> >> Jorg
> >>
> >> On Sun, Oct 4, 2015 at 5:23 PM Andrei Shakirin <as...@talend.com>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> 2.5 to 3 minutes is quite long even for 15 clients initialization.
> >>> Did you specify wsdlLocation attribute in jaxws:client? Can performance
> >>> be related to remote WSDL downloading?
> >>> Could you bind any profiling tool and discover which operation caused
> >>> performance problem?
> >>>
> >>> Regards,
> >>> Andrei.
> >>>
> >>>> -----Original Message-----
> >>>> From: Jorg Heymans [mailto:jorg.heymans@gmail.com]
> >>>> Sent: Donnerstag, 1. Oktober 2015 08:45
> >>>> To: users@cxf.apache.org
> >>>> Subject: ReflectionServiceFactoryBean performance
> >>>>
> >>>> Hi,
> >>>>
> >>>> We have about 15 jaxws client definitions in our application context
> >>> defined
> >>>> like this :
> >>>>
> >>>> <jaxws:client id="myService" serviceClass="my.service.Service"
> >>>> address="http://....."/>
> >>>>
> >>>> Initializing all of these during startup takes on average about 2.5 to
> >>> 3 minutes.
> >>>> This is already after adding -
> >>>> Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true , before
> >>> that it
> >>>> was more like 5-6 minutes.
> >>>>
> >>>> Is there a way to improve this ? We are going to add more services as
> >>> the
> >>>> application grows, and already now this cxf init takes up more than
> >>> half of our
> >>>> deployment time.
> >>>>
> >>>> Thanks,
> >>>> Jorg Heymans
> >>>
> >>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: ReflectionServiceFactoryBean performance
Posted by Daniel Kulp <dk...@apache.org>.
> On Oct 5, 2015, at 6:12 AM, Jorg Heymans <jo...@gmail.com> wrote:
> It seems that jaxb context init is still the culprit. We use the
> com.sun.xml.bind.v2.ContextFactory , switching for example to the
> Eclipselink implementation
> (org.eclipse.persistence.jaxb.JAXBContextFactory) was even slower. Spring's
> lazy init is no good here, makes me wonder if cxf could do a 'true' lazy
> init and defer this expensive init of the service until actual methods are
> called on it. Feasible ?
Not really, no. We need the information from the context to check to make sure the methods on the clients are even valid.
It’s possible that 15 clients are creating 15 unique JAXB Contexts. One thing you could TRY is collect ALL the classes that are used by all 15 clients and do one of:
1) Add @XmlSeeAlso annotations or similar to pull in all the classes
2) Use the “jaxb.additionalContextClasses” property to provide a list of all the classes
<jaxws:properties>
<entry key="jaxb.additionalContextClasses">
<bean class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
<property name="classNames">
<list>
<value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</value>
</list>
</property>
</bean>
</entry>
</jaxws:properties>
3) Possibly create a list of all the classes and pre-initialize via the JAXBContextCache.getCachedContextAndSchemas method. I’m not 100% sure this will work.
Basically, if you can get ONE large JAXBContext serving all the clients, it might be quicker than 15 smaller. Not really sure though.
Dan
>
> Jorg
>
> On Mon, Oct 5, 2015 at 10:42 AM Jorg Heymans <jo...@gmail.com> wrote:
>
>>
>> The wsdlLocation attribute is not specified, and to be honest i have no
>> idea if there is any remote downloading involved during startup. We just
>> specify id and serviceClass attribute and let cxf do its thing. I will
>> try to profile and report back.
>>
>> Jorg
>>
>> On Sun, Oct 4, 2015 at 5:23 PM Andrei Shakirin <as...@talend.com>
>> wrote:
>>
>>> Hi,
>>>
>>> 2.5 to 3 minutes is quite long even for 15 clients initialization.
>>> Did you specify wsdlLocation attribute in jaxws:client? Can performance
>>> be related to remote WSDL downloading?
>>> Could you bind any profiling tool and discover which operation caused
>>> performance problem?
>>>
>>> Regards,
>>> Andrei.
>>>
>>>> -----Original Message-----
>>>> From: Jorg Heymans [mailto:jorg.heymans@gmail.com]
>>>> Sent: Donnerstag, 1. Oktober 2015 08:45
>>>> To: users@cxf.apache.org
>>>> Subject: ReflectionServiceFactoryBean performance
>>>>
>>>> Hi,
>>>>
>>>> We have about 15 jaxws client definitions in our application context
>>> defined
>>>> like this :
>>>>
>>>> <jaxws:client id="myService" serviceClass="my.service.Service"
>>>> address="http://....."/>
>>>>
>>>> Initializing all of these during startup takes on average about 2.5 to
>>> 3 minutes.
>>>> This is already after adding -
>>>> Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true , before
>>> that it
>>>> was more like 5-6 minutes.
>>>>
>>>> Is there a way to improve this ? We are going to add more services as
>>> the
>>>> application grows, and already now this cxf init takes up more than
>>> half of our
>>>> deployment time.
>>>>
>>>> Thanks,
>>>> Jorg Heymans
>>>
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: ReflectionServiceFactoryBean performance
Posted by Jorg Heymans <jo...@gmail.com>.
Hi,
It seems that jaxb context init is still the culprit. We use the
com.sun.xml.bind.v2.ContextFactory , switching for example to the
Eclipselink implementation
(org.eclipse.persistence.jaxb.JAXBContextFactory) was even slower. Spring's
lazy init is no good here, makes me wonder if cxf could do a 'true' lazy
init and defer this expensive init of the service until actual methods are
called on it. Feasible ?
Jorg
On Mon, Oct 5, 2015 at 10:42 AM Jorg Heymans <jo...@gmail.com> wrote:
>
> The wsdlLocation attribute is not specified, and to be honest i have no
> idea if there is any remote downloading involved during startup. We just
> specify id and serviceClass attribute and let cxf do its thing. I will
> try to profile and report back.
>
> Jorg
>
> On Sun, Oct 4, 2015 at 5:23 PM Andrei Shakirin <as...@talend.com>
> wrote:
>
>> Hi,
>>
>> 2.5 to 3 minutes is quite long even for 15 clients initialization.
>> Did you specify wsdlLocation attribute in jaxws:client? Can performance
>> be related to remote WSDL downloading?
>> Could you bind any profiling tool and discover which operation caused
>> performance problem?
>>
>> Regards,
>> Andrei.
>>
>> > -----Original Message-----
>> > From: Jorg Heymans [mailto:jorg.heymans@gmail.com]
>> > Sent: Donnerstag, 1. Oktober 2015 08:45
>> > To: users@cxf.apache.org
>> > Subject: ReflectionServiceFactoryBean performance
>> >
>> > Hi,
>> >
>> > We have about 15 jaxws client definitions in our application context
>> defined
>> > like this :
>> >
>> > <jaxws:client id="myService" serviceClass="my.service.Service"
>> > address="http://....."/>
>> >
>> > Initializing all of these during startup takes on average about 2.5 to
>> 3 minutes.
>> > This is already after adding -
>> > Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true , before
>> that it
>> > was more like 5-6 minutes.
>> >
>> > Is there a way to improve this ? We are going to add more services as
>> the
>> > application grows, and already now this cxf init takes up more than
>> half of our
>> > deployment time.
>> >
>> > Thanks,
>> > Jorg Heymans
>>
>
Re: ReflectionServiceFactoryBean performance
Posted by Jorg Heymans <jo...@gmail.com>.
The wsdlLocation attribute is not specified, and to be honest i have no
idea if there is any remote downloading involved during startup. We just
specify id and serviceClass attribute and let cxf do its thing. I will try
to profile and report back.
Jorg
On Sun, Oct 4, 2015 at 5:23 PM Andrei Shakirin <as...@talend.com> wrote:
> Hi,
>
> 2.5 to 3 minutes is quite long even for 15 clients initialization.
> Did you specify wsdlLocation attribute in jaxws:client? Can performance be
> related to remote WSDL downloading?
> Could you bind any profiling tool and discover which operation caused
> performance problem?
>
> Regards,
> Andrei.
>
> > -----Original Message-----
> > From: Jorg Heymans [mailto:jorg.heymans@gmail.com]
> > Sent: Donnerstag, 1. Oktober 2015 08:45
> > To: users@cxf.apache.org
> > Subject: ReflectionServiceFactoryBean performance
> >
> > Hi,
> >
> > We have about 15 jaxws client definitions in our application context
> defined
> > like this :
> >
> > <jaxws:client id="myService" serviceClass="my.service.Service"
> > address="http://....."/>
> >
> > Initializing all of these during startup takes on average about 2.5 to 3
> minutes.
> > This is already after adding -
> > Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true , before that
> it
> > was more like 5-6 minutes.
> >
> > Is there a way to improve this ? We are going to add more services as the
> > application grows, and already now this cxf init takes up more than half
> of our
> > deployment time.
> >
> > Thanks,
> > Jorg Heymans
>
RE: ReflectionServiceFactoryBean performance
Posted by Andrei Shakirin <as...@talend.com>.
Hi,
2.5 to 3 minutes is quite long even for 15 clients initialization.
Did you specify wsdlLocation attribute in jaxws:client? Can performance be related to remote WSDL downloading?
Could you bind any profiling tool and discover which operation caused performance problem?
Regards,
Andrei.
> -----Original Message-----
> From: Jorg Heymans [mailto:jorg.heymans@gmail.com]
> Sent: Donnerstag, 1. Oktober 2015 08:45
> To: users@cxf.apache.org
> Subject: ReflectionServiceFactoryBean performance
>
> Hi,
>
> We have about 15 jaxws client definitions in our application context defined
> like this :
>
> <jaxws:client id="myService" serviceClass="my.service.Service"
> address="http://....."/>
>
> Initializing all of these during startup takes on average about 2.5 to 3 minutes.
> This is already after adding -
> Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true , before that it
> was more like 5-6 minutes.
>
> Is there a way to improve this ? We are going to add more services as the
> application grows, and already now this cxf init takes up more than half of our
> deployment time.
>
> Thanks,
> Jorg Heymans