gRPC UnsupportedAddressTypeException，但仅当与shadowJar一起打包时

问题描述 投票：0回答：4

我有一个简单的 gRPC 客户端，由 Gradle 使用 ShadowJar 打包在 jar 中。当我使用 IntelliJ 运行 

main()
时，RPC 发送成功。当我使用 
java -jar
运行它时，出现异常：

更新：我想我已经确定 IntelliJ 和 ./gradlew ShadowJar 提供了同一组类，但顺序不同。我怀疑这会导致不同的行为，但我真的不明白为什么，或者在任何一种情况下如何控制类路径的顺序。如果我能弄清楚哪些类实际上与这里相关，那将会有很大的帮助。完整扩展包括 19k 类文件。

Exception in thread "main" io.grpc.StatusException: UNKNOWN
        at io.grpc.Status.asException(Status.java:550)
        at io.grpc.kotlin.ClientCalls$rpcImpl$1$1$1.onClose(ClientCalls.kt:296)
        at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:562)
        at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:70)
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInternal(ClientCallImpl.java:743)
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:722)
        at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
        at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:133)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.nio.channels.UnsupportedAddressTypeException
        at java.base/sun.nio.ch.Net.checkAddress(Net.java:146)
        at java.base/sun.nio.ch.Net.checkAddress(Net.java:157)
        at java.base/sun.nio.ch.SocketChannelImpl.checkRemote(SocketChannelImpl.java:816)
        at java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:839)
        at io.netty.util.internal.SocketUtils$3.run(SocketUtils.java:91)
        at io.netty.util.internal.SocketUtils$3.run(SocketUtils.java:88)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
        at io.netty.util.internal.SocketUtils.connect(SocketUtils.java:88)
        at io.netty.channel.socket.nio.NioSocketChannel.doConnect(NioSocketChannel.java:322)
        at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.connect(AbstractNioChannel.java:248)
        at io.netty.channel.DefaultChannelPipeline$HeadContext.connect(DefaultChannelPipeline.java:1342)
        at io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:548)
        at io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:533)
        at io.netty.channel.ChannelDuplexHandler.connect(ChannelDuplexHandler.java:54)
        at io.grpc.netty.WriteBufferingAndExceptionHandler.connect(WriteBufferingAndExceptionHandler.java:157)
        at io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:548)
        at io.netty.channel.AbstractChannelHandlerContext.access$1000(AbstractChannelHandlerContext.java:61)
        at io.netty.channel.AbstractChannelHandlerContext$9.run(AbstractChannelHandlerContext.java:538)
        at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:503)
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:995)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        ... 1 more

我的客户（这似乎不是问题）：

fun main() {
    runBlocking {
        SampleClient().hello("hello")
    }
}
class SampleClient() : Closeable {
    private val channel = ManagedChannelBuilder.forAddress("localhost", StationController.PORT).usePlaintext().build()
    private val stub = StationServiceGrpcKt.StationServiceCoroutineStub(channel)
    suspend fun hello(msg: String) {
        val request = helloRequest { message = msg }
        stub.hello(request)
    }
    override fun close() {
        channel.shutdown().awaitTermination(5, TimeUnit.SECONDS)
    }
}

使用 

java -jar build/libs/test-0.1-all.jar
运行失败，出现上述异常。使用 
java -classpath <very long classpath> com.test.MainKt
运行成功。

我尝试最小化仍然显示此行为的 gradle.build.kts：

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
import com.google.protobuf.gradle.*

plugins {
    kotlin("jvm") version "1.7.10"
    id("com.github.johnrengelman.shadow") version "6.0.0"
    id("com.google.protobuf") version "0.8.19"
}

// These address this error:
// 'compileJava' task (current target is 17) and 'compileKotlin' task (current target is 1.8) jvm target compatibility
// should be set to the same Java version.
java { sourceCompatibility = JavaVersion.VERSION_17; targetCompatibility = JavaVersion.VERSION_17 }
tasks.withType<KotlinCompile> { kotlinOptions { jvmTarget = "17" } }

group = "com.test"
version = "0.1"

repositories { mavenCentral() }

dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.3")
    implementation("io.grpc:grpc-protobuf:1.48.1")
    implementation("io.grpc:grpc-kotlin-stub:1.3.0")

    // The rpc fails only when I run it from the fat jar. running from intellij works. the stacktrace is all in netty,
    // but when I compile without netty there is no netty in the jar, making me think there is no transitive dependency
    // on netty. it fails with both netty and netty-shaded, but with different stack traces.
    // with netty-shaded, it says Caused by: io.grpc.netty.shaded.io.netty.channel.AbstractChannel$AnnotatedConnectException: connect(..) failed: Address family not supported by protocol: /localhost:8980
    // with netty, it just says Caused by: java.nio.channels.UnsupportedAddressTypeException
    implementation("io.grpc:grpc-netty:1.48.1")

    implementation("com.google.protobuf:protobuf-kotlin:3.21.4")
}

// for gRPC
protobuf {
    protoc { artifact = "com.google.protobuf:protoc:3.21.4" }
    plugins {
        // We only need this for Kotlin, but it doesn't fully link without the java sources.
        id("grpc") { artifact = "io.grpc:protoc-gen-grpc-java:1.48.1" }
        id("grpckt") { artifact = "io.grpc:protoc-gen-grpc-kotlin:1.3.0:jdk8@jar" }
    }
    generateProtoTasks {
        all().forEach {
            it.plugins { id("grpc"); id("grpckt") }
            // The plugins above (I think) generate the Java proto code, but not the extra Kotlin stuff like DSLs.
            // Including this adds a /kotlin folder to the generated code which contains all the extra stuff.
            it.builtins { id("kotlin") }
        }
    }
}


sourceSets {
    main {
        java {
            // These are the default generated source dirs, but they have to be added manually currently:
            // https://github.com/google/protobuf-gradle-plugin/issues/109
            // The plugin generates both a grpc dir with Java files, and grpckt with Kotlin files. I believe the grpckt
            // contents includes all the functionality of the grpc (java) contents, but I'm not positive. The kotlin
            // files might just be stubs for the java version? so maybe this compiles but doesn't run?
            srcDirs("build/generated/source/proto/main/grpc")
            srcDirs("build/generated/source/proto/main/grpckt")
            // This contains the Java classes like the request and response messages.
            srcDirs("build/generated/source/proto/main/java")
            // This contains the Kotlin extensions to those java classes, like DSLs.
            srcDirs("build/generated/source/proto/main/kotlin")
        }
    }
}

tasks.jar { manifest.attributes["Main-Class"] = "com.test.MainKt" }

我不知道如何继续调试它。

intellij-idea build.gradle grpc gradle-kotlin-dsl shadowjar
4个回答
8
投票

一位朋友找到了答案。对 build.gradle.kts 的添加最终使其发挥作用：

tasks.named("shadowJar", ShadowJar::class) {
    mergeServiceFiles()
}

请参阅 ShadowJar 的 文档，了解此处发生的情况。摘要：“Java 库通常在 JAR 的 META-INF/services 目录中包含服务描述符文件。服务描述符通常包含特定服务支持的以行分隔的类列表。在运行时，读取并使用该文件配置库或应用程序行为。

多个依赖项可能使用相同的服务描述符文件名。在这种情况下，通常希望将文件的每个实例的内容合并到单个输出文件中。” 

mergeServiceFiles()
就是这样做的。

4
投票

此问题是由于在 grpc-java v1.47.0 及更高版本中使用某些 Maven 插件时，名称解析被破坏

 导致的。

使用

maven-assembly-plugin

 时，可以使用
容器描述符处理程序 来解决。文件 assembly.xml
 应包括：

<assembly xmlns="http://maven.apache.org/ASSEMBLY/2.1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.1.1 http://maven.apache.org/xsd/assembly-2.1.1.xsd"> .... <containerDescriptorHandlers> <containerDescriptorHandler> <handlerName>metaInf-services</handlerName> </containerDescriptorHandler> </containerDescriptorHandlers> </assembly> 
这里是assembly.xml
构建具有依赖项的JAR的示例。


对于 
maven-shade-plugin
 
资源转换器 实现这一点：

<configuration>
    <transformers>
        <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
    </transformers>
<configuration>

    



    

    
    
    

    

        

            

                

                    
2
投票

                    
                

            

        

        
我在使用 
grpc
 和使用 
maven-assembly-plugin
 时遇到了同样的问题。
我通过将程序集插件更改为 
maven-shade-plugin
 并包含 ServicesResourceTransformer
 和 
ManifestResourceTransformer
 转换器来将元 inf 文件包含到最终的 Jar 中来解决这个问题。

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <shadedArtifactAttached>true</shadedArtifactAttached>
                <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer">
    
                    </transformer>
                    <transformer implementation=
                                         "org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>com.PaxosServer</mainClass>
                    </transformer>
                </transformers>
            </configuration>
        </execution>
    </executions>
</plugin>


    



    

    
    
    

    

        

            

                

                    
0
投票

                    
                

            

        

        


tasks {
  shadowJar {
    mergeServiceFiles()
  }
}


    
	

    

    


  

  

    
最新问题


  





  

    © www.soinside.com 2019 - 2024. All rights reserved.