Make it possible to disable the BackgroundPreinitializer

[dsyer]

E.g. if you know you are running in a single CPU, there's no point trying to do it in the background. It's just cost. It's more common than you might expect because container management platforms all try to restrict CPU access, and even hypervisors, potentially.

If you know that you are running an app in that kind of environment, it's pointless creating extra threads on startup, and there is a cost, so it would be useful to switch it off.

Also just to be able to measure the effect of the initializer accurately it would help to be able to disable it.

[philwebb]

It would have to be quite low level since that thing starts so early. Would an environment variable be enough?

[dsyer]

Yeah that's what I was thinking (environment variable or system property).

[ayudovin]

@philwebb, As far as I understand we should check if property disable we don't need to start extra thread.
This property should be located in Environment variable but on this stage environment variable isn't available yet. Does it mean system.getProperty() should use in this case ?
Correct me if I'm wrong.

[snicoll]

@ayudovin you are correct. We can't use the Environment at this point so System.getProperty is a good idea (and relaxed binding can't really apply there). I think we should probably also discuss the name of this property as it's slightly unusual.

[ayudovin]

@snicoll, what do you think about spring.background-preinitializer.extra-thread.enable ?

[snicoll]

Thanks for the feedback. We don't use - in prefix and since we're not going to use relaxed binding for this I am tempted to make it way shorter.

Perhaps @dsyer has an idea?

[philwebb]

Take a look at CachedIntrospectionResults.IGNORE_BEANINFO_PROPERTY_NAME from Spring Framework. That's a pretty similar idea.

[ayudovin]

@snicoll spring.backgroundpreinitializer.ignore ?

[philwebb]

@ayudovin Sounds good to me, we can easily change it later if necessary.

[snicoll]

Ditto, thanks @ayudovin!