You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remove unused providers when configuring the server #9832
In order to improve startup, we should avoid loading unnecessary providers at startup (and unnecessary init). This should also help to achieve a lower memory fingerprint because only the expected providers are supposed to be loaded.
Currently, we already do that by checking whether or not a provider is disabled so that it is not added to the list of installed providers hence not loaded/inited at startup.
However, we should check if we can also keep only the default provider for certain Spi, for instance, have a single provider when loading providers of X509ClientCertificateLookupSpi. The same goes for any other Spi whose providers do not change at runtime and are supposed to have a single one installed. For instance, UserProfileSpi or ScriptingSpi.
Another example is the implementation of the map storages which should not be loaded at all in case JPA is being used.
This seems like we'd need to mark relevant spi's as having singleton providers. However the effect of this would likely need to be opt-in.
If not, there is always a possibility that custom logic may use one of the other getProvider methods to obtain one of the other enabled providers.
Since there isn't a significant init cost nor memory footprint to the provider factories mentioned in request, most of the startup cost (loading the spi / providers, determining the defaults) has been moved to build-time, and there hasn't been movement on the issue in 3 years, resolving as not planned.
Yeh, it was just one I copied with a batch of others. when moved from jira at the time the quarkus foundation wasn't really there as it is now. Greetings to everyone.
Activity
shawkins commentedon Aug 10, 2025
This seems like we'd need to mark relevant spi's as having singleton providers. However the effect of this would likely need to be opt-in.
If not, there is always a possibility that custom logic may use one of the other getProvider methods to obtain one of the other enabled providers.
Since there isn't a significant init cost nor memory footprint to the provider factories mentioned in request, most of the startup cost (loading the spi / providers, determining the defaults) has been moved to build-time, and there hasn't been movement on the issue in 3 years, resolving as not planned.
DGuhr commentedon Aug 10, 2025
Yeh, it was just one I copied with a batch of others. when moved from jira at the time the quarkus foundation wasn't really there as it is now. Greetings to everyone.