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 <[email protected]> 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 <[email protected]> > 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:[email protected]] >> > Sent: Donnerstag, 1. Oktober 2015 08:45 >> > To: [email protected] >> > 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 >> >
