SmallRye Config integration with SmallRye Fault Tolerance

[sergey-morenets]

Hi

Is it possible to integrate SmallRye Config and SmallRye Fault Tolerance? Documentation has no mentioning whether it's possible or not. I assume that Microprofile Fault Tolerance can be used when we call a method of our CDI bean. But what if we have some external configuration (Zookeeper, Consul) and we want to apply some of the fault tolerance strategies (retry, timeout)? Configuration loading happens when Jakarta EE container bootstraps.

I tried to add ConfigSourceInterceptor but it seems that @Retry annotation is not used here:

@Priority(Priorities.LIBRARY + 1)
public class RetryInterceptor implements ConfigSourceInterceptor {

	@Override
	@Retry(maxRetries = 2)
	public ConfigValue getValue(ConfigSourceInterceptorContext context, String name) {
		return context.proceed(name);
	}
}

This is feature is somewhat nice to have. For example, Spring Cloud has smooth integration with Spring Retry.

[Ladicek]

I'm no expert on MP Config, but I guess this is again about config not having access to CDI, because "mumble mumble bootstrap something" :laughing:

I mean, I think ConfigSourceInterceptor implementations are discovered by ServiceLoader and are not CDI beans, so interceptors don't apply. Hence @Retry is meaningless.

It would be really nice if MP Config had a clear delineation between bootstrap config and regular config, then perhaps the regular config could use CDI (and hence possibly use MP Fault Tolerance), but I don't really know what that would entail. Perhaps the MP Config folks already work on that.

[sergey-morenets]

I'm no expert on MP Config, but I guess this is again about config not having access to CDI, because "mumble mumble bootstrap something" 😆

I mean, I think ConfigSourceInterceptor implementations are discovered by ServiceLoader and are not CDI beans, so interceptors don't apply. Hence @Retry is meaningless.

It would be really nice if MP Config had a clear delineation between bootstrap config and regular config, then perhaps the regular config could use CDI (and hence possibly use MP Fault Tolerance), but I don't really know what that would entail. Perhaps the MP Config folks already work on that.

Thank you. Can you please add documentation entry that Fault Tolerance is not supported yet but will be supported in the future releases?

[radcortez]

Yes, ConfigSourceInterceptor is loaded by the ServiceLoader and used internally in the SR Config chain. The Config is also loaded by the ServiceLoader and CDI just exposes this.

Ideally, Config should be a base spec where other specs build upon, like CDI. We already have a few situations where developers want to use CDI in Config objects, and you get into this chicken / egg problem. You want to configure CDI with Config, but want to inject CDI bean in Config :)

Regarding integration of Config with FT Retry, it may be possible to do something internally, but no promises. I'll try to think on something :)

[Ladicek]

I think FT can (and should) provide a programmatic API that would be usable in the absence of CDI. That's the cleanest solution IMHO. (Sorry, I don't have a specific date or planned release for that feature. I wanted to add it for a long time, but something more important always came up :-) )

[radcortez]

That may help, but it won't resolve the issue where people expect to put the annotations and work out of the box.

[Ladicek]

I don't think we should evoke an impression that fault tolerance will work on classes that are not CDI beans. That's a deeeeep rabbit hole :-)

[radcortez]

Yes. In this case, my idea was to convert the interceptor chain to be CDI based if you are in a CDI environment. The main issue is that with our current architecture, I would need to mutate the Config object, which I'm not really eager to do :)