Initialization Timing Issue

[objec]

I'm working on a very heavily threaded app that, when running on our higher-end Sun hardware we experience an issue that I cannot reproduce on single proc desktops.

The problem is that Spring (2.0m2) is throwing NoSuchBeanDefinitionException exceptions on some of the very first getBean() calls. But on subsequent calls, just milliseconds later and with the same bean names, succeed. Thus I believe there to be a timing issue with our initialization code.

We have a helper class that holds a reference to and initializes our spring context via a synchronized method. Here's the guts of the init method:

applicationContext = new GenericApplicationContext();
XmlBeanDefinitionReader xmlReader = new XmlBeanDefinitionReader( applicationContext );
xmlReader1.loadBeanDefinitions( ...resource... );
applicationContext.refresh();

I believe the call to refresh is returning before all of the beans are assessable. And due to our heavily threaded access, there is a very small period of time where getBean calls are failing before the beans are fully loaded (assessable).

I don’t know if this is related, but we do define multiple names for some of the beans and I have only seen failures on look ups by the aliases. But that might just be related to the order of calls in our code. Here's an example config:

<bean name="datasource-ABC,datasource-XYZ" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">

Is there a way I can detect if all the beans are accessible? If before returning from our init method, I lookup all the beans with the following code, I don't see the problem. This could be due simply to the delay imposed by this loop....and it sure seams like a hack:

List beanNameList = Arrays.asList( applicationContext.getBeanDefinitionNames() );
for ( Iterator beanNames = beanNameList.iterator(); beanNames.hasNext(); ){
applicationContext.getBean( (String)beanNames.next() );
}

thanks.
-peter

[Costin Leau]

loadBeandefinitions should not return unless all the beans are initialized. It does seem that you might have concurrency problem but I'm not sure what's the cause - Spring doesn't use any background thread to do the parsing and it tries to be as stateless as possible - unless the context is bootstrapped in a weird way or you have some threads that modify the application context I don't see a reason why multiple threads should make the appcontext throw exceptions.

[objec]

Upon some additional investigation it turned out to be a bug in the helper. Thanks for confirming that it was not Spring.