cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Question about Optimization to only load the first extension found when only one is asked for.
Date Mon, 16 Jun 2014 15:21:55 GMT

On Jun 15, 2014, at 7:23 AM, Jason Pell <jason@pellcorp.com> wrote:

>    Optimization to only load the first extension found when only one is
> asked for.
> 
> Broke some code our project uses.  We are overriding the
> JettyHTTPServerEngineFactory with our own extended one.   And because the
> ConfiguredBeanLocator would return our bean first in the getBeansOfType
> call we were able to successfully override JettyHTTPServerEngineFactory
> with our own.
> 
> With the change in 2.7.12-SNAPSHOT to always look for a bean of a specific
> name first, our override never gets a look in.
> 
> I have worked around it by naming our overridden
> JettyHTTPServerEngineFactory bean the same as the one included by cxf
> itself, so it again gets to be the chosen extension.
> 
> But I was curious as to why this change was made.

The primary reason was to make sure we’re not loading a bunch of things that we know will
never be used.  Basically, lower the memory footprint and make startup a little bit faster.
  For example, we now have two different HTTPConduitFactory implementations.  With the old
behavior, BOTH were being loaded, but only the first one (maybe, more on that in a sec)  actually
registered as an extension and thus the second was was loaded, held onto by the extension
object, possibly consuming threads for its thread pool and such, lifecycle listeners created/added/called,
but not actually used.   The change made sure only one is loaded.

Related notes:
In SOME cases, it wasn’t the first one that was used, it was the last one.   That was really
bizarre as it was supposed to be the first.  Definitely trying to make things more predictable
and consistent. 

There were a couple of race conditions in the code as well.  This was the source of a lot
of the random failures in the systests/ws-rm.  If two (or more) threads requested the RMManager
at the same time, they were getting different instances and thus the maps of sequence ID’s
didn’t line up and such.


-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message