Feature request: Lazyload bean object ... Eager Singletons vs Lazy Singletons

[Travisnv]

Hi @rbygrave, I see generated code eagerly create object when we build BeanScope. Can we make the process a bit more memory friendly by only construct beans beforehand if we desire so? Otherwise, the beans are created when we call scope.get().

Of course, we need configuration for that during build scope, something like:

BeanScope beanScope = BeanScope.newBuilder()...(false).build();

SomeBean bean = beanScope.get(SomeBean.class);
=> this bean is created when we explicitly call by scope object.

Thanks and Regards,
Travis

[rbygrave]

Well probably not no. There are previous discussions on why we desire not to lazy instantiate beans and desire to have BeanScope as effectively immutable so it is unlikely.

That said, what is the underlying motivation here? Can you describe the scenario more explicitly where we desire to only wire some of the beans on demand?

[rbygrave]

Eager Singletons (not Lazy Singletons)

Firstly noting that as I see it there is not a global industry convention that all DI containers follow. For example, Spring DI is eager by default and Micronaut is lazy by default. So there are different opinions as to what is the best default.

• Spring DI has default eager singletons and this is my defacto bias based on many years of using Spring DI.
• Micronaut has default lazy singletons but that can be changed globally. I first found this out when I saw confusion with people asking why their PostConstruct methods were not firing with Micronaut.
• Guice as I see it we choose more explicitly eager or lazy.

Why does avaje-inject have a bias to eager singletons?

• Server apps in Kubernetes (K8s readiness probe)
• Time to first response
• Simplicity when BeanScope is effective immutable (for server apps)
• We can use Custom scopes to choose when to wire things
• Built in @TestScope for expensive tests dependencies (like docker containers)
• Wiring is not expensive anymore?

1. Server apps in Kubernetes (K8s readiness probe)

In short services have liveness and readiness probes/endpoints.
liveness ~= "app is starting but not ready to take requests yet"
readiness ~= "app has started, everything is good, it is ready to take requests"
K8s effectively supports declarative blue/green rollout of services.

e.g. We have 3 instances/pods of my-service version 1 running. We ask K8's to rollout version 2 of that service

• 1 instance of my-service version 2 is started
• K8's waits for it to get to readiness ok 200 status, when it does then it brings that instance into the cluster
• We now have 3 instances of my-service version 1 and 1 instance/pod of my-service version 2
• K8's can now gracefully terminate one of the my-service version 1 instances
• rinse and repeat until all the pods/instances are my-service version 2

Now the main point here is that a K8 service should ONLY advertise readiness ok (200 response) when it is truely and honestly ready. If it connects to databases, queues, any interesting resource it should do this before it returns readiness ok. If any of these fail (can't connect to database) the service should not come up, not say readiness ok (it goes into crash loop).

The implication is that any singleton that does expensive stuff (say cache warming) or any risky stuff that might fail (establish tcp connections etc) should be wired eagerly before readiness ok.

It is good and proper for an application to fail fast.

2. Time to first response

This is to say that when a service is ready it ideally is ready for production load. It isn't great for a service to come in too cold and for the first response to take significantly longer to execute because it actually was not initialised or it is being initialised in a thread safe manor and we have locking involved so multiple concurrent requests are waiting on locks as initialisation is occurring.

It is not great to be "up" but slightly suck performance wise - being "really cold" is bad.

3. Simplicity when BeanScope is effective immutable (for server apps)

With eager initialisation we have the case that our BeanScope is effectively immutable. So in our server app space we can expect it to take a lot of concurrent requests and that is all good and simple. The only caveat is around shutdown and running preDestroy methods - we want that to occur when the app no longer has requests. K8's makes graceful shutdown nice - we just should be conscience that preDestory lifecycle is typically mutating our BeanScope (and for server apps we want that to happen after the point the service has stopped getting load / new requests).

If we don't have this simplicity then BeanScope needs to initialise things in the face of potentially many concurrent requests. It is not sufficient to use a ConcurrentHashMap - lots of things now have race conditions (with likely fast paths and slow paths implementation wise).

4. Custom scopes

The expected way to "not wire a bunch of things" with avaje-inject is to use a custom scope and then ONLY create that custom scope when needed. So if we have an app with say 10 dependencies that we want to wire / create lazily we can put them all in the same custom scope and then only wire that scope when needed.

5. @TestScope for component tests

avaje-inject has built in @TestScope specifically to wire expensive test dependencies (like docker containers). For example, wiring up a docker container like localstack for testing purposes. This test scope is special in that it exists for the scope of ALL TESTS so it is different and special and deals specifically with test dependencies that are relatively expensive and that we prefer not to wire for each and every individual test.

6. Wiring is not expensive anymore?

Optional wiring is a big thing / big feature in Spring DI and Micronaut. Only wire X based on various optional things.

Now back in the day a project had a large modular monolith spring app and this app took maybe 2 mins to startup. This type of experience is where this motivation comes from as I see it. Also as I see it people are somewhat going to trend back from everything being a microservice to some more modular monolith service apps. So personally I think conditional wiring is going to be more of a big thing going forward for these modular monolith apps.

However, wiring 1000 things with Dagger2 DI is roughly / approximately something like invoking 1000 methods plus some overhead (I am guessing here but it is very very close to manual written code that only invokes the injection methods). Now it takes next to no time for the JVM to execute that 1000 methods. avaje-inject does a little more than Dagger2 but not a whole lot more. avaje-inject conditionally checks if something should be wired or if it is already provided plus avaje-inject registers the wired instance into it's map. So wiring 1000 things with avaje-inject might be in the order of executing 5000 methods. For example, all the unit tests in avaje-inject pretty much wire the whole graph for each and every test invocation (and we don't really notice or care).

The way Dagger2 and avaje-inject work puts it into the "wiring is not expensive" world - this is very very different to how micronaut and spring actually work in that wiring for them is still a visible/noticeable expense. Micronaut uses annotation processing but largely only generates meta data and some stuff to avoid reflection - this is very different to what dagger and avaje-inject are doing.

Dagger2 and avaje-inject actually do the vast majority of DI work at compile time so that the actually wiring is just running a bunch of methods (that have already been ordered appropriately) and the JVM chomps that up without blinking. DI in a dagger/avaje-inject world is super cheap.

[Travisnv]

Thanks @rbygrave. Your explanation with clear motivation is absolutely amazing. I now understand more about avaje-inject development context and what aspects the library aims to solve. If someday, this part of explanation go to documentation page then it would be great for the project.

About my request, it is already on your "guess": making wiring as fast as possible. I make a new entry point for my application and want to start a test to multiple environments. One environment will need a particular set of tests to be executed and sometimes, it is only a small part of the application. So far so good @rbygrave.

Cheers,
Travis

[rbygrave]

Yeah cool. Yes this does need to be part of the docs :)