[Inquiry] Current platform supports no known thread pool resources

[stevepentland]

Inquiry

during startup in our deployed docker container we are presented with the following:

Exception in thread "main" java.lang.RuntimeException: Current platform supports no known thread pool resources
    at glide.connectors.resources.Platform.getThreadPoolResourceSupplier(Platform.java:67)
    at glide.api.BaseClient.createClient(BaseClient.java:364)
    at glide.api.GlideClient.createClient(GlideClient.java:90)
    at <removed>(ValkeyClient.kt:99)
    at <removed>(ValkeyClient.kt:101)
    at <removed>(DistributedLockV2.kt:34)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
    at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:277)
    at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:95)
    at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:69)
    at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source)
    at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:48)
    at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source)
    at <removed>.<init>(DistributedLockV2.kt:33)
    at <removed>(DistributedLock.kt:20)
    at <removed>(Main.kt:192)
    at <removed>(Main.kt:89)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:569)
    at kotlin.reflect.jvm.internal.calls.CallerImpl$Method.callMethod(CallerImpl.kt:97)
    at kotlin.reflect.jvm.internal.calls.CallerImpl$Method$Static.call(CallerImpl.kt:106)
    at kotlin.reflect.jvm.internal.KCallableImpl.callDefaultMethod$kotlin_reflection(KCallableImpl.kt:208)
    at kotlin.reflect.jvm.internal.KCallableImpl.callBy(KCallableImpl.kt:112)
    at io.ktor.server.engine.internal.CallableUtilsKt.callFunctionWithInjection(CallableUtils.kt:119)
    at io.ktor.server.engine.internal.CallableUtilsKt.executeModuleFunction(CallableUtils.kt:36)
    at io.ktor.server.engine.ApplicationEngineEnvironmentReloading$launchModuleByName$1.invoke(ApplicationEngineEnvironmentReloading.kt:331)
    at io.ktor.server.engine.ApplicationEngineEnvironmentReloading$launchModuleByName$1.invoke(ApplicationEngineEnvironmentReloading.kt:330)
    at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.avoidingDoubleStartupFor(ApplicationEngineEnvironmentReloading.kt:355)
    at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.launchModuleByName(ApplicationEngineEnvironmentReloading.kt:330)
    at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.access$launchModuleByName(ApplicationEngineEnvironmentReloading.kt:32)
    at io.ktor.server.engine.ApplicationEngineEnvironmentReloading$instantiateAndConfigureApplication$1.invoke(ApplicationEngineEnvironmentReloading.kt:311)
    at io.ktor.server.engine.ApplicationEngineEnvironmentReloading$instantiateAndConfigureApplication$1.invoke(ApplicationEngineEnvironmentReloading.kt:309)
    at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.avoidingDoubleStartup(ApplicationEngineEnvironmentReloading.kt:337)
    at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.instantiateAndConfigureApplication(ApplicationEngineEnvironmentReloading.kt:309)
    at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.createApplication(ApplicationEngineEnvironmentReloading.kt:150)
    at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.start(ApplicationEngineEnvironmentReloading.kt:276)
    at io.ktor.server.netty.NettyApplicationEngine.start(NettyApplicationEngine.kt:216)
    at io.ktor.server.netty.EngineMain.main(EngineMain.kt:23)
    at <removed>(Main.kt:70)

We build our jars on Linux and package them in to matching docker images. These are then deployed to Kubernetes. We are already using netty and I'm not sure why valkey-glide would believe there are no thread pool resources available.

I have attempted to use the Kotlin example to include both valkey-glide and one of the netty transports listed as needed via

implementation("io.valkey:valkey-glide:1.+:$classifier")
implementation("io.netty:${nettyTransport()}:4.1.100.Final:$classifier")

The same result has happened with or without the implementation("io.netty:${nettyTransport()}:4.1.100.Final:$classifier") being in my build.gradle.kts file

Language

Java (kotlin)

Language Version

No response

Engine Version

Valkey 8.0.1

Operating System

Linux - Docker - amazoncorretto:17-alpine3.18

Additional Technical Information

No response

[jamesx-improving]

Hi Steve,

This looks similar to a netty related dependency issue.

Could you please take a look at the actual version of netty pulled?

[stevepentland]

@jamesx-improving sure I'll take a look. I'm not really used to dealing with Java and dependencies so it may take a while. We package in to a fat jar for execution, but I'll see if I can figure out the various versions that got pulled in during build.

It looks like we got netty-transport-native-epoll.version=4.1.112.Final for the transport though.

[stevepentland]

actually I realized that using valkey-glide like this will not work for us as we need to be able to run our images on both arm and x86 machines. So choosing the netty transport and classifier for valkey-glide at build time via osdetector will not result in what we need in general. Is there a way to just include all of the required platform specific items in all builds?