cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tully, Gary" <Gary.Tu...@iona.com>
Subject RE: Profiling jaxws.ServiceImpl.createPort(..)
Date Thu, 26 Jul 2007 14:03:31 GMT
Hi Dan,
Thanks for your suggestion, it provides a quick win. I have added a
patch to
https://issues.apache.org/jira/browse/CXF-850
That adds the JAXBContext cache based on Set<Class<?>>. The only gotcia
was the smarts we had to add the ws-addressing classes on the fly.
The majority of the other work that is repeated on multiple calls to
getPort is the cxf service/endpoint/binding memory model from the wsdl.
I added a comment to this effect to the jira.
The problem with caching the model is that we currently effect the model
with endpoint address information at runtime which I think is bad. In an
ideal world, any model that is build from wsdl should be read-only. With
a bit of luck I will get around to looking at this in more detail in the
future.

Would someone have a moment to review and apply the patch:
https://issues.apache.org/jira/secure/attachment/12362609/jaxb_context_c
ache.gtully.patch

Thanks,
Gary.

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 20 July 2007 00:42
> To: cxf-dev@incubator.apache.org
> Subject: Re: Profiling jaxws.ServiceImpl.createPort(..)
> 
> Hi Gary,
> 
> AFAIK, the RI should cache contexts already based on the 
> Classes used to create the context. Or at least thats what 
> the JAXB spec highly recommends.
> If you're going to try implementing a cache in 
> JAXBDataBinding I would recommend keying on a Set of Classes 
> instead of the interface. Different services may be 
> configured differently - what really matters are the 
> classes/packages used to create the context. You can check 
> out how I did it inside the SXC JAXBContextImpl here:
> 
> http://svn.sxc.codehaus.org/browse/sxc/trunk/sxc-jaxb/src/main
/java/com/envoisolutions/sxc/jaxb/JAXBContextImpl.java?r=32
> 
> I know that some of the XmlSchema code can be sped up 
> significantly.  I started this one day, but it seemed to be a 
> 8-10 hour exercise instead of a
> 1-2 hour one. They problem is the XmlSchema is needlessly 
> recreating NamespaceContexts. But the code isn't very 
> amenable to changing this - it needs a bit of refactoring and love :-)
> 
> Another option for speedup is to extend SXC so it generates 
> pre-compiled readers/writers for various JAXBContexts at 
> build time. This would mean we could avoid creating an RI 
> version of the JAXBContext altogether and startup would be 
> nearly instantaneous. The only tricky part is determining 
> what the set of context classes is...
> 
> Hope that helps,
> 
> - Dan
> 
> On 7/19/07, Tully, Gary <Gary.Tully@iona.com> wrote:
> >
> >
> > Hi,
> >
> > Has anyone looked at caching JAXBContexts on a per jaxws 
> service basis?
> >
> > I have been looking at the cpu profile of calls to
> > org.apache.cxf.jaxws.ServiceImpl.createPort()
> >
> > The bulk of the work is split between two tasks, building the 
> > JAXBBContext and building the XmlSchemaCollection from the 
> wsdl model.
> >
> > In an application that makes many calls to 
> getPort()/createPort() it 
> > may make sense to cache both of these.
> >
> > The XMLSchemaCollection is very much part of the WSDL 
> Definition so a 
> > cache of the schemas could be something a  JAXB specific/aware 
> > WSDLManager could maintain.
> >
> >
> > The JAXBContext is a little more complex because of the variety of 
> > entry points to it's creation.
> >
> > As an experiment, I splashed a static cache into
> > JAXBDataBinding.initialize() based on Service QName. 
> Initial results 
> > were great for my simple test case but the CodeFirstTest 
> showed up the 
> > error in my ways as it builds a context from a class rather than a 
> > complete wsdl model. Caching on interface class gives 
> better results.
> >
> > A static cache will not be a winner, some one of bus or ServiceImpl 
> > will need to manage the cache or reuse factory beans but 
> there is no 
> > clear owner of the process that results in JAXBContext creation.
> >
> > Before I look more into this I want to know if anyone has 
> looked into 
> > caching JAXBContexts or has any ideas?
> >
> > Thanks in advance,
> > Gary.
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland) Registered Number: 
> > 171387 Registered Address: The IONA Building, Shelbourne 
> Road, Dublin 
> > 4, Ireland
> >
> 
> 
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
View raw message