search

quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.57k stars 2.63k forks source link

JTA bootstrap to avoid FS scanning #13779

Open Sanne opened 3 years ago

Sanne commented 3 years ago

Description I noticed the that the Narayana bootstrap process is looking in many places to try find its default configuration settings, to allow for a lot of flexibility about where such files can be stored. IMO such flexibility is maybe necessary in other systems, but it's a non-feature in Quarkus as it conflicts with our principles.

For example, I just observed it looking into /opt/jdk1.8.0_211/jre/jbossts-properties.xml , and to do so it first had to also crawl environment variables to figure out were I'm having my JDKs.

This should have a single place to look into for its default settings - and I think this should be represented as Java code, as a constant. Configuration overrides should be controlled by our central standardized configuration file application.properties, and nothing else.

Why?

Implementation ideas This is all performed by the com.arjuna.common.util.propertyservice.FileLocator . One solution could be to allow plugging in a simplified FileLocator implementation; but I think we could take it a step further and not need any of the code in AbstractPropertiesFactory ? Ideally use a different PropertiesFactory which has hardcoded defaults, or maybe it's BeanPopulator which could use a bytecode-generated implementation via Gizmo?

@gytis WDYT ?

gytis commented 3 years ago

I don't work in the Narayana team any more, so I cannot say if this would be acceptable or not. Although this does sound reasonable and we have exactly the same issue in the Narayana Spring Boot starter. Maybe @mmusgrov could provide some input?

Sanne commented 3 years ago

oops, sorry Gytis :) I remember now, old habits.

ochaloup commented 3 years ago

This could be partially related to https://github.com/quarkusio/quarkus/issues/6654

Sanne commented 3 years ago

@ochaloup yes, I think it could be interesting to dedicate some days to review the Narayana bootstrap process as a whole.

I'd suggest take a baseline metric of bootstrap efficiency, and try to improve on it - both in terms of speed and (native) memory. XML parsing, Loading of XML parsers, filesystem loading and resource loading are all just implementation details of the same problem - I'm sure you might be able to find other improvements in the area if you happen to be able to zoom into the process :)