On startup performance.....

[Daniel Kulp <dk...@apache.org>]

I'm thinking a bit more about startup performance things and one  
thought that comes to mind is the number of beans in the META-INF/cxf/ 
cxf.xml file.  Everything in there are "core" components (which is why  
they are in core) and the Bus would pretty much not work without  
them.   Would it make sense to just move the construction of some of  
them into the CXFBusImpl constructor?   Some of the stuff would need  
to remain (spring specific stuff), but things like the WSDLManager,  
PhaseManager, etc.... where there isn't any spring related  
configuration could easily be pulled out.


Thoughts?

---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: On startup performance.....

[hyd techie <ve...@gmail.com>]

Hi ,

We have an Application which is using Artix 5.1 JAX-WS Spring
configuration(nothing but Apache CXF) with 1 endpoint registered through
spring configuration.The requirment is
that the time out on the client side is just 60secs...we have noticed that
the requests to this endpoint(on startup and after a gap around 2hrs )always
timeout.The performance is about 10fold worser sometimes.

Can some one pls suggest a work around or fix for this ?.This issue is a
high priority as this stopping the sign off before production.

Thanks a lot in advance.

Best Regards,
Hyd
-- 
View this message in context: http://www.nabble.com/On-startup-performance.....-tp17282256p18720873.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: On startup performance.....

[Benson Margulies <bi...@gmail.com>]

I'm not sure that the per-bean overhead of spring is significant
compared to the overall background noise of using Spring at all, or at
least of using Spring with XML. I was thinking about how hard it would
be to go to zero-xml -- have our own factory that didn't read xml, not
even from fastinfoset, for the core configuration.

We could use cascading contexts: we could have a context that
'springs' into life with the core, always-the-same, beans, and then a
normal XML context that cascades to it for the optional items.

I could be wrong here: it could be that moving more initialization
from beans declared in Spring to ordinary objects created by the
default bus would in fact be a win.