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:[EMAIL PROTECTED] > Sent: 20 July 2007 00:42 > To: [email protected] > 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 <[EMAIL PROTECTED]> 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
