You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Tully, Gary" <Ga...@iona.com> on 2007/07/19 19:41:10 UTC
Profiling jaxws.ServiceImpl.createPort(..)
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
RE: Profiling jaxws.ServiceImpl.createPort(..)
Posted by "Tully, Gary" <Ga...@iona.com>.
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 <Ga...@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
Re: Profiling jaxws.ServiceImpl.createPort(..)
Posted by Dan Diephouse <da...@envoisolutions.com>.
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 <Ga...@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