cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Profiling jaxws.ServiceImpl.createPort(..)
Date Thu, 19 Jul 2007 23:42:23 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message