Closed ModAlpha closed 7 months ago
I'm seeing this on 1.61.0 as well (also on grpc-netty-shaded
and jvm 17
), looks like a regression due to changes in .getNameResolver. This worked fine in previous versions (I'm upgrading from 1.57.2).
Briefly looking at the code, .forAddress(..)
ends up building a target for the channel in GrpcUtil.class#L542 using a null URI scheme.
Then, the string result is parsed again as a URI and the default scheme of the NameResolverRegistry is used: ManagedChannelImpl.getNameResolver#L732
For both of us, that default scheme ends up being unix
(i.e. unix domain sockets), which is not was asked for when initially doing .forAddress(...)
.
Some progress on this & solution: the NameResolverProvider
being used is picked by the JDK from META-INF/services/io.grpc.NameResolverProvider
.
The default in that file for the grpc-core.jar
is io.grpc.internal.DnsNameResolverProvider
.
However, the grpc-netty-shaded.jar
also has the same file in META-INF
, but this time containing io.grpc.internal.UdsNameResolverProvider
(the Unix Domain Socket resolver provider).
When building the fat jar, this latter file is what ends up for me in META-INF
, leading to unix
being the default scheme being considered, and the dns
scheme not being present. We need the file from grpc-core
in the fat jar.
The solution would be to use the shadow gradle plugin and have something like
shadowJar {
mergeServiceFiles()
}
in your build file in order to merge the settings across dependencies.
In other words, I believe the original report is not a bug but intended behaviour.
Is there a (clean) solution for folks using Ant? (Yes, I am *required to use Ant for my project)
Currently, I need to manually concatenate (i.e. merge) the contents of all instances of the NameResolverProvider
service descriptor file into a single file, delete all instances from the jar, and then finally copy the merged service descriptor back into the jar.
@ModAlpha, you are very likely making a "fat" jar without configuring the combining tool to merge service files. The fix depends on what tool you are using to make the fat jar. Looks like I've provided a breadcrumb at https://github.com/grpc/grpc-java/issues/10826#issuecomment-1896254509 before.
Seems like this is resolved. If not, comment, and it can be reopened.
I encountered this today with a KTor project deployed to App Engine. I use shadowJar to generate my fatJar and the fix was to add mergeServiceFiles() to the shadowJar
task in Gradle. Here's the relevant part of my build.gradle.kts:
tasks.register<ShadowJar>("shadowJar") {
mergeServiceFiles()
// other configurations
}
I am using the latest version of grpc.
I have ktor server app and I'm using gradle as build tool and using this dependency for gRPC implementation("io.grpc:grpc-netty-shaded:1.61.0") on my mac M1 and jdk 17 and gradle 8.5.0 and I'm connecting to another service via gRPC
when running the app via IntelliJ IDEA all fine but when running the app via fat jar this exception occur