Null dependencies result when multiple calls to getBean for the same bean are made asynchronously

[mawaruDOLL]

I'm working with a ColdFusion project using FW/1 and DI/1 whose front end provides dashboards for viewing data. Each dashboard is comprised of widgets that give the user a specific view of or information about some data. The data for each widget is loaded via separate Ajax calls, so multiple calls can be made at the same time which use the same server side resources (services, beans, etc...). The widget data loaded by the Ajax calls is actually coming from a subsystem, which I don't think is a factor in the situation I'm seeing but I'll mention in case I have overlooked something.

I have found that reloading on such a page can result in null dependencies in beans and services, which causes exceptions to occur when calls are made to the injected services' methods. I believe what is happening is that one request begins the resolution process for a Bean in resolveBean, then another request starts it again and sets the dependencies to null, after which the first request will likely finish by setting the dependencies to null in the accumulator cache because the second request wiped out the resolved dependencies that the first request had already set up. After that, the injected dependencies will continue to be null until a successful reload is done since they are null in the accumulator cache. The issue pops up unpredictably because it's caused by a race condition.

[aliaspooryorik]

I have a similar setup to you describe and have not seen these issues, so from what you've said very hard to have any insight I'm afraid. Please can you provide more information - for example:

• what version of FW/1 and DI/1 are you using.
• what is your reloadApplicationOnEveryRequest is set to?
• do you have a stack trace?
• what CF Engine are you running on?
• Can you replicate it using a load test like jMeter?

etc

[mawaruDOLL]

The application is using Lucee 5 and version 4.2.0 of FW/1. I tried using the beta of 4.3 as well and was able to trigger the error. I attempted to put together a small application to demonstrate the problem but the error just wasn't happening. In the application were it is happening, there is a subsystem that is is added to the parent bean factory in Application.cfc.

beanFactory.declare('databrowser').asValue(getSubsystemBeanFactory('databrowser').getBean('databrowser'))

This databrowser singleton has a few methods that call getBean() to get the same transient bean which resides in the subsystem bean factory. When several calls are made very close to each other, sometimes the bean doesn't get its services injected. On our test server, we see this happen about once a month under normal application usage. But spamming the page with F5 and reload=true can also make it happen. My best idea on how to fix it was to extend ioc and override resolveBean() to lock per bean so that each bean can only execute the resolution process once even if there are multiple calls to getBean(). I know it's not ideal but I didn't get the error anymore after implementing that change.