[英]Microprofile Config: Dynamic ConfigSource values for faulttolerance metric tags
i'm currently working on a solution to setting metric tags for the microprofile fault-tolerance framework .我目前正在研究为微配置文件容错框架设置度量标签的解决方案。 We're using it together with metrics, but one cannot directly set tags via the fault-tolerance annotations.
我们将它与指标一起使用,但不能通过容错注释直接设置标签。
So we came up with a workaround setting a ThreadLocal
value via an Interceptor, which then is read by a custom ConfigSource
.所以我们想出了一个解决方法,通过 Interceptor 设置
ThreadLocal
值,然后由自定义ConfigSource
读取。 The ConfigSource
checks for "mp.metrics.tags"
and "MP_METRICS_TAGS"
config keys in it's getValue(final String propertyName)
method. ConfigSource
在其getValue(final String propertyName)
方法中检查"mp.metrics.tags"
和"MP_METRICS_TAGS"
配置键。 This would basically work if the getValue
would get called every time a fault-tolerance annotation is processed.如果每次处理容错注释时都会调用
getValue
,这基本上可以工作。 But is seems like this is not the case and the invocations of the method happen randomly.但似乎情况并非如此,并且该方法的调用是随机发生的。
In my oppinion ConfigSources and their getValue(final String propertyName)
should always get called as a developer might rely on config values which could change every second.在我看来 ConfigSources 和他们的
getValue(final String propertyName)
应该总是被调用,因为开发人员可能依赖于每秒都会改变的配置值。
Any ideas why the config source is not called?为什么不调用配置源的任何想法?
It looks like the custom ConfigSource
does no longer get called when returning null
multiple times or at least during the server startup phase.看起来自定义
ConfigSource
在多次返回null
时或至少在服务器启动阶段不再被调用。 In the mentioned scenario this can be bypassed by returning an empty string.在提到的场景中,这可以通过返回一个空字符串来绕过。 Then the
ConfigSource
also gets called for every getValue()
method call at runtime.然后在运行时每次调用
getValue()
方法都会调用ConfigSource
。
The MicroProfile Config 1.4 specification indicates that no caching of a ConfigSource
's value should occur , so if your MicroProfile Config Config
implementation (you don't say which implementation it is) is caching the results of a call to ConfigSource#getValue()
it is not compliant, as best as I can tell (the specification is flawed, not very rigorous, and its TCK is spotty but it certainly seems to be pretty clear on this issue). MicroProfile Config 1.4 规范表明不应缓存
ConfigSource
的值,因此如果您的 MicroProfile Config Config
实现(您没有说它是哪个实现)正在缓存调用ConfigSource#getValue()
的结果不合规,据我所知(规范有缺陷,不是很严格,它的 TCK 参差不齐,但在这个问题上似乎很清楚)。
(Do note that a given ConfigSource
implementation may, of course, decide to return cached values from its getValue()
method.) (请注意,给定的
ConfigSource
实现当然可能决定从其getValue()
方法返回缓存值。)
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.