Config property not found when in ForkJoin common Pool thread

[florentgarin]

Describe the bug

Fetching a config property on ForkJoin common Pool thread failed.
Be aware that the behavior is not the same in dev mode and in prod mode as it's work in dev mode.

Expected behavior

Same behavior in prod and dev mode is expected, cfg must be returned.

Actual behavior

In prod mode, reading a property set in application.properties fails (return null).

How to Reproduce?

For instance :

ThreadContext threadContext = ThreadContext.builder()
.propagated(ThreadContext.ALL_REMAINING)
.cleared(ThreadContext.TRANSACTION)
.build();
var expirationTask = threadContext.contextualRunnable(() -> {
var cfg = ConfigProvider.getConfig().getOptionalValue("smallrye.jwt.sign.key.location", String.class).orElse(null);
});
CompletableFuture.runAsync(expirationTask, delayedExecutor(60, TimeUnit.SECONDS));

cfg is null.

Output of uname -a or ver

#36-Ubuntu SMP Thu Aug 26 19:22:09 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk version "11.0.11" 2021-04-20 OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2) OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2, mixed mode, sharing)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.1.3

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[geoand]

@radcortez I think this is something we have seen before, no?
I remember something about us not being able to set the TCCL of the FJ pool...

[radcortez]

Yes, most likely the issue is that the classloader being returned does not have any Config associated, so a new default Config is created and that may or may not work, depending on the configuration being retrieved.

The safe way to do this is to just retrieve the configuration value before and just pass down the value.

I remember something about us not being able to set the TCCL of the FJ pool...

Yes, I think I remember something about this as well, but can't find it. I'm now sure if this was a Zulip discussion or if we have anything here in GH.

[florentgarin]

Yes

Yes, most likely the issue is that the classloader being returned does not have any Config associated, so a new default Config is created and that may or may not work, depending on the configuration being retrieved.

Yes I guessed that.

The safe way to do this is to just retrieve the configuration value before and just pass down the value.

Yes, we implemented that workaround but not always as easy as it seems as the value could be loaded by third library. For instance io.smallrye.jwt.build.Jwt read "smallrye.jwt.sign.key.location".

I remember something about us not being able to set the TCCL of the FJ pool...

Yes, I think I remember something about this as well, but can't find it. I'm now sure if this was a Zulip discussion or if we have anything here in GH.

[florentgarin]

One more thing, the workaround does not look acceptable for a long term solution in my opinion as it breaks the Dev/prod parity principle.

[radcortez]

Some additional information here (to not replicate, since it is a bit long conversation):
https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/ForkJoin.20CL/near/253421142

[radcortez]

@florentgarin a more acceptable solution might be to use the ManagedExecutor (either by injection one or building your own) instead of the default FJ pool. The ManagerExecutor should have the right CL set and you shouldn't have any issues retrieving the Config instance inside the task.

[florentgarin]

ManagedExecutor does not permit to delay execution (see my sample code), otherwise I would use it.
Anyway, I'm not looking for a workaround for my personal case (already wrote one) but I'm reporting that issue to improve that awesome framework!

[radcortez]

Thanks. I already know what the issue is. It may take some time to get to an agreeable solution and I didn't want to leave you without a quick answer.