[jboss-dev] Plain Java IoC : Re: Small boottime improvement

[Kabir Khan]

I did an alternative dependency resolution prototype [1] where I did basic indexing of depenencies. It performed much better than the existing dependency resolution algorithm when everything is deployed in the wrong order, but I did not really see the performance gains I was hoping for in AS, since dependencies are not all deployed in the wrong order there. When things are deployed more or less in the right order, it did not make much difference. 

Then again, it was just a proof of concept so it is doable, but still not as efficient as it could be. For example I only try to resolve the dependencies of contexts who match a dependency of a recently incremented context, but I still try to resolve all those dependencies rather than tracking all the dependencies. I might pick it up again once some of the other "perfomance noise" from VFS, MDR and other core projects is gone, since there are definitely a few of the fixes that I have done the past week or so that should have an impact on this as well.

[1] http://community.jboss.org/thread/146838?tstart=0

On 18 Feb 2010, at 02:06, David M. Lloyd wrote:

> I agree in theory, but disagree in practice, sort of.
> 
> If we had a theoretical service container which had "perfect" scalability 
> characteristics (in other words, fully graph-based, so starting one service 
> requires only visiting its dependents and dependencies one time), and a 
> simple plain-Java way to declare services (e.g. a "Service" interface with 
> stop/start methods and a simple callback-based injection system), then 
> there is absolutely no reason why we wouldn't want every last thing to be 
> dependency-managed, because it would essentially eliminate start-order bugs 
> and would actually vastly simplify everything.
> 
> The reason that it doesn't work in practice is that (a) the internal MC 
> dependency resolution mechanisms and state machine is really complex, and 
> doesn't scale linearly and (b) it's much harder to use than it should be. 
> And (c) the core system has too many features, making (a) and (b) really 
> hard to solve.  I firmly believe that a simple concurrent dependency graph 
> system with two basic states - UP and DOWN - is all that's needed - 
> everything else, including autowiring, the reflective POJO stuff, the JMX 
> magic, the existing notion of service controller states, etc. are not 
> required but could all be rebuilt on top of this basic system and would 
> work much more efficiently for it, possibly retaining some or maybe even 
> full compatibility with the current implementation.
> 
> The reason everyone wants to use MC is because of the above theory - that 
> if we do, everything will work as smoothly and efficiently as possible, and 
> rather than working out a very complex startup process, we can instead 
> define our startup process delcaratively (which will produce a far faster 
> and more efficient startup sequence than mere humans can figure out, with a 
> fraction of the effort).  However I don't see that being the case today. 
> The situation is not hopeless - Ales, Kabir & team have been really digging 
> into it - but it seems pretty discouraging at the moment.  We're never 
> going to get there from here without some major critical rethinking of 
> basic ideas.
> 
> - DML
> 
> On 02/17/2010 08:20 AM, Bill Burke wrote:
>> IoC can be done in plain Java.  Using the MC to manage every nut and
>> bolt is just plain ridiculous.
>> 
>> IMO, you will only ever need this flexibility between releases.  You
>> will never be asking a customer to change these things.  Therefore, IMO,
>> plain Java IoC and delegation are good enough for the majority of the
>> ridiculous amount of EJB and Web Services internals that are exposed
>> currently within XML scripting.  Coarse grain "wrapper" components will
>> both hide complexity from users and boost performance, without
>> disrupting flexibility.
>> 
>> For example, when I did Embedded EJB the first time, I created a *very*
>> coarse grain bean for datasources that manually created the JCA
>> components I needed to deploy.  With this type of wrapper bean,
>> configuration is just calling constructors and setter methods.  For
>> start/stop you either delegate or manually register with the MC,
>> although delegation, IMO, is better.
>> 
>> Carlo de Wolf wrote:
>>> Although I agree that we have user configuration and internal
>>> configuration mixed up in a lot of places, I don't agree on using other
>>> IoC constructs to resolve internal concerns. We want flexibility on
>>> every level and I would need an IoC construct anyway. So we should be
>>> able to use MC for all scenarios and fix the scalability issue where it
>>> lies.
>>> 
>>> Carlo
>>> 
>>> On 02/12/2010 02:34 PM, Dimitris Andreadis wrote:
>>>> I had seen something similar long time ago when measuring the memory footprint of an MBean,
>>>> it was quite significant.
>>>> 
>>>> It would be interesting to measure the memory overhead of a POJO (metadata and all), but as
>>>> Bill suggest, having more coarse grained POJOs is better than many fine grained ones.
>>>> 
>>>> Bill Burke wrote:
>>>> 
>>>>> Brian Stansberry wrote:
>>>>> 
>>>>>>> * How about making our bean.xml files more coarse grain?  Meaning *A
>>>>>>> LOT* less implementation details exposed through XML.  You can do IoC in
>>>>>>> Java you know.  The vast majority of details within all our beans.xml
>>>>>>> files will never ever change, nor will we want to support users changing
>>>>>>> this stuff.  If our beans.xml file are reduced to a few bean definitions
>>>>>>> and classes, would make parsing and creating bean metadata much much faster.
>>>>>>> 
>>>>>>> 
>>>>>> Semi-related, the ServiceBindingManager config needs a schema and a
>>>>>> parser. I create a lot of MC beans for SBM, most of which the MC has no
>>>>>> need to know anything about.
>>>>>> 
>>>>>> 
>>>>> EJB and Webservices create an insane amount of beans that can probably
>>>>> be collapsed into a few beans.
>>>>> 
>>>>> 
>>>>> 
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> 
>>> 
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development