APPSERV-141 Adds Caching to MicroProfile Config

Question

Summary

This PR adds basic caching to MP Config implementation. I also did clean and correct generics and types in the module and some other cleanup.

• adds caching to PayaraConfig
• adds a command to set the cache duration in seconds (default is 60s)
• adds or corrects generics in the module
• replaces use of Type in connection with Converters with Class (it never was Type based and only actual values that would work needed to be Classes)
• splits the automatic converter into a method based and a constructor based one (was one before that used one or the other)
• fixes extracting type a Converter implementation converts (it would just pick the first type parameter of the first implemented interface with ParameterizedType which could be something other than Converter)
• cleanup of existing tests (remove sysouts, unused and unnecessary methods)
• fixes potential NPE introduced by APPSERV-59 https://github.com/jbee/Payara/blob/a4cdc26fe6aaa895e558dee3e191451d9a309af2/nucleus/payara-modules/nucleus-microprofile/config-service/src/main/java/fish/payara/nucleus/microprofile/config/spi/ConfigSourceComparator.java (the implementation is not wrong but apparently MP Config TCK uses sources which return null for name)

Q & A

Q: Does changing the cache duration need a server restart to become effective A: It depends. As each application has its Config instance any change will have an effect for applications deployed after the change. Those deployed before will not change.

Q: Is caching compliant with MP Config standard? A: Yes and No. The specification explicitly names that caching can be applied to individual ConfigSources. It also states that each time getValue is used all sources are considered which means that even with caching in some sources the work needed to be done is about the same and caching on source level is really just helpful for sources that involve particularly slow operations like looking up the property in a database. Given this situation I decided that the best we can do is cache properties for only a short time. Each property has its own TTL (default is 1 min). As this is strictly speaking no longer compliant with the specification the TTL can be configured 0 to disable caching. This way users can opt for better performance for price of small delay before value change in a source becomes effective or being standard compliant with worse performance. The default is caching enabled as users usually want good performance and usually are happy to wait up to 1 minute for changes to propagate. I also created https://github.com/eclipse/microprofile-config/issues/552 where I suggest a similar solution be added to the spec.

Q: Why would caching be needed? A: Numbers. A new MetricID does look up two configurations. A Metric lookup might do 1-3 of these. A FT method might involve 2-8 of these. Each looking in up to 10ish sources. Most sources being a map of some sorts. This multiplies to a worse case of 2 * 3 * 8 * 10 = 480 map lookups for a single FT method invocation. :worried:

Q: What exactly is cached? A: Result values. The cache contains the values that are returned by calling getValue and alike. This means they also help avoid finding the appropriate converter and applying conversion each time the method is called.

Testing

This PR adds tests that verify that the fixed Converter type extraction works correctly and that the PayaraConfig in general in specifically the added caching works correctly.

Testing Performed

Besides running the unit tests MP Config TCK is run against remote server. (also see https://github.com/payara/MicroProfile-TCK-Runners/pull/108)

bash
export my_int_property=45
export MY_BOOLEAN_PROPERTY=true
export my_string_property=haha
export MY_STRING_PROPERTY=woohoo
export MP_CONFIG_CACHE_DURATION=0
cd {payara-bin-dir}
asadmin start-domain
cd {tck-dir}
mvn clean install "-Ppayara-server-remote" "-Dpayara.version=5.202"

and also as (requires being build before locally)

bash
mvn clean install "-Dpayara.version=5.202-SNAPSHOT"

as well as MP Metrics TCK against remote:

bash
export MP_METRICS_TAGS=tier=integration
...
asadmin start-domain
...
mvn clean install "-Ppayara-server-remote" "-Dpayara.version=5.202"

and MP FaultTolerance TCK

bash
mvn clean install "-Ppayara-server-remote" "-Dpayara.version=5.202"

Documentation

https://github.com/payara/Payara-Server-Documentation/pull/730

该提问来源于开源项目：payara/Payara

Answer 1

jenkins test please