1.8. 已知问题
查看以下已知问题以了解红帽构建的 Quarkus 3.20 限制和临时解决方案。
1.8.1. FIPS:在启用了 FIPS 的环境中测试时的已知问题
在 Red Hat build of Quarkus 3.20 中,进行了测试,以评估 Quarkus 应用程序在启用了 FIPS (Federal Information Processing Standards)模式的环境中的行为。
测试通常成功完成时,一些技术集成和原生镜像配置目前存在阻止验证或编译的限制。
在启用了 FIPS 的环境中测试显示几个关键组件的成功结果,包括 OpenID Connect (OIDC)、支持的数据库、缓存、在非原生模式和 OpenTelemetry 中与 Kafka 的消息。但是,目前无法在这些环境中验证一些技术集成和原生配置。
这些发现结果并不表示红帽构建的 Quarkus 或其组件对 FIPS 的官方支持。
无法验证的场景
以下技术集成或配置目前在启用了 FIPS 的环境中无法验证:
- MariaDB 11.x
- 在 JVM 和原生模式下使用 Mandrel 23.0 和 23.1 的 Infinispan 客户端扩展
- 在原生模式中使用 SCRAM 和 OAUTHBEARER SASL 机制的 Apache Kafka
- 原生模式中的 JDBC MSSQL 驱动程序
- DB2
- 原生模式的 reactive MSSQL 客户端
- 使用 Red Hat Mandrel 23.1 构建器镜像的原生镜像编译
重要的相关问题
以下公共 JIRA 票据提供了遇到的限制的更多详情:
- QUARKUS-5984 :由于兼容性问题,MariaDB 11.x 无法在启用了 FIPS 的环境中连接。
- QUARKUS-2036: Infinispan 客户端扩展缺少对启用了 FIPS 的环境的支持。
- QUARKUS-2984 :使用 JDBC MSSQL 和 Reactive MSSQL 客户端的本地构建在启用了 FIPS 的 RHEL 8 上会失败。
- QUARKUS-5232: SASL SCRAM 机制在启用了 FIPS 的环境中的原生模式下不可用。
- QUARKUS-5233: SASL OAUTHBEARER 机制在启用了 FIPS 的环境中的原生模式下不可用。
- MANDREL-254: Mandrel 23.1 构建器镜像需要重新工作以支持启用了 FIPS 的环境。
- QUARKUS-4387: Quarkus Reactive MySQL 客户端在启用了 FIPS 的环境中不被支持。
- QUARKUS-4612 :在带有原生 Mandrel 23.0 和 23.1 的 FIPS 上 Infinispan 客户端扩展会失败。
临时解决方案
当前还没有可用的临时解决方案。
此发行注记旨在在更广泛的兼容性测试时抢占披露已知挑战。
1.8.2. Kafka Streams 扩展在 Microsoft Windows 上缺少原生库
由于缺少原生库 librocksdbjni-win64.dll
,在 Microsoft 上使用 quarkus-kafka-streams
扩展的应用程序会在运行时会失败。
在启动过程中,这个问题会抛出以下错误:
java.lang.RuntimeException: librocksdbjni-win64.dll was not found inside JAR
这个错误可防止初始化 RocksDB 组件,这是 Kafka Streams 应用程序所需的。
目前还没有可用的临时解决方案。
错误示例
13:07:08,118 INFO [app] ERROR: Failed to start application (with profile [prod]) 13:07:08,118 INFO [app] java.lang.RuntimeException: Failed to start quarkus 13:07:08,118 INFO [app] at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source) 13:07:08,118 INFO [app] at io.quarkus.runtime.Application.start(Application.java:101) 13:07:08,118 INFO [app] at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:111) 13:07:08,118 INFO [app] at io.quarkus.runtime.Quarkus.run(Quarkus.java:71) 13:07:08,118 INFO [app] at io.quarkus.runtime.Quarkus.run(Quarkus.java:44) 13:07:08,118 INFO [app] at io.quarkus.runtime.Quarkus.run(Quarkus.java:124) 13:07:08,118 INFO [app] at io.quarkus.runner.GeneratedMain.main(Unknown Source) 13:07:08,118 INFO [app] Caused by: java.lang.ExceptionInInitializerError 13:07:08,118 INFO [app] at io.quarkus.kafka.streams.runtime.KafkaStreamsRecorder.loadRocksDb(KafkaStreamsRecorder.java:14) 13:07:08,118 INFO [app] at io.quarkus.deployment.steps.KafkaStreamsProcessor$loadRocksDb1611413226.deploy_0(Unknown Source) 13:07:08,118 INFO [app] at io.quarkus.deployment.steps.KafkaStreamsProcessor$loadRocksDb1611413226.deploy(Unknown Source) 13:07:08,118 INFO [app] ... 11 more 13:07:08,118 INFO [app] Caused by: java.lang.RuntimeException: librocksdbjni-win64.dll was not found inside JAR. 13:07:08,118 INFO [app] at org.rocksdb.NativeLibraryLoader.loadLibraryFromJarToTemp(NativeLibraryLoader.java:118) 13:07:08,118 INFO [app] at org.rocksdb.NativeLibraryLoader.loadLibraryFromJar(NativeLibraryLoader.java:102) 13:07:08,118 INFO [app] at org.rocksdb.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:82) 13:07:08,118 INFO [app] at org.rocksdb.RocksDB.loadLibrary(RocksDB.java:70) 13:07:08,118 INFO [app] at org.rocksdb.RocksDB.<clinit>(RocksDB.java:39) 13:07:08,118 INFO [app] ... 14 more
如需更多信息,请参阅 QUARKUS-3434。
1.8.3. 在 Windows 上缺少 Snappy 的原生库
在 Red Hat build of Quarkus 3.20 中,在 Windows 上运行使用 Snappy 压缩库的应用程序会因为缺少原生库而产生错误。
当尝试压缩 Windows 环境中带有 Snappy 的数据时,用户可能会遇到类似以下示例的错误消息。
错误信息示例
... org.eclipse.microprofile.reactive.messaging.Message$5@1e8dc267 from channel 'test' was not sent to Kafka topic 'test' - nacking message: org.apache.kafka.common.KafkaException: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Windows and os.arch=x86_64 ...
临时解决方案:目前还没有可用的临时解决方案。计划在以后的发行版本中解决这个问题。
如需更多信息,请参阅 QUARKUS-5983。
1.8.4. 原生镜像构建会间歇性失败,在 Mandrel 23.1 上无法访问类型错误
在 Red Hat build of Quarkus 3.20 中,使用 Mandrel 23.1 运行时构建原生镜像可能会因为堆快照验证错误而失败。
构建过程失败并显示一个错误,表示类型没有标记为 reachable :
AnalysisType<... reachable: false>
这些错误不一致,并可能在不同应用程序中发生。在受控的环境中,它们尚未可靠复制。
错误 1 示例
com.oracle.graal.pointsto.util.AnalysisError: The heap snapshot verifier discovered a type not marked as reachable: AnalysisType<VMOption$Origin[] -> HotSpotType<[Lcom/sun/management/VMOption$Origin;, resolved>, allocated: false, inHeap: false, reachable: false> at com.oracle.graal.pointsto.heap.HeapSnapshotVerifier$ScanningObserver.ensureTypeScanned(HeapSnapshotVerifier.java:332) ...
错误 2 示例
AnalysisType<MemoryType[] -> HotSpotType<[Ljava/lang/management/MemoryType;, resolved>, allocated: false, inHeap: false, reachable: false> AnalysisType<HotSpotDiagnosticMXBean$ThreadDumpFormat[] -> HotSpotType<[Lcom/sun/management/HotSpotDiagnosticMXBean$ThreadDumpFormat;, resolved>, allocated: false, inHeap: false, reachable: false>
错误 3 示例
AnalysisType<MemoryType[] -> HotSpotType<[Ljava/lang/management/MemoryType;, resolved>, allocated: false, inHeap: false, reachable: false>
临时解决方案:重试原生镜像构建。由于问题是间歇性的,因此构建可能会在后续尝试时成功。
计划在以后的发行版本中解决这个问题。
如需更多信息,请参阅 MANDREL-332。
1.8.5. Quarkus CLI 无法解析红帽构建的 Quarkus TLS 插件
红帽构建的 Quarkus 3.15 添加了 Quarkus TLS 命令行界面(CLI)插件。
但是,开发工具目前不会发现在 maven.repository.redhat.com
上托管的 Quarkus CLI 插件。因此,Quarkus CLI 默认无法找到 TLS 插件。
临时解决方案:
要启用 Quarkus CLI 来解析插件,请将 JBang 配置为使用 maven.repository.redhat.com
。您可以执行以下操作之一:
创建包含以下内容的
jbang.properties
文件:run.repos=central,https://maven.repository.redhat.com/ga/
将此文件放在项目的根目录中,以便在本地或
~/.jbang
目录中配置 CLI,以全局应用配置配置。如果已安装 JBang,使用以下命令进行全局配置:
jbang config set run.repos central,https://maven.repository.redhat.com/ga/
如需更多信息,请参阅 QUARKUS-5183。
1.8.6. Quarkus CLI 只更新红帽构建的 Quarkus 平台版本
在 Red Hat build of Quarkus 3.20 中,运行 update 命令只更新红帽构建的 Quarkus 平台 com.redhat.quarkus.platform
中包含的 BOM。如果版本的一部分、quarkus-qpid-jms-bom
和 quarkus-operator-sdk-bom
,则可以包括 quarkus-camel-bom
和 quarkus-camel-bom 和 quarkus-cxf-bom
。
但是,该命令不会更新与上游社区版本关联的 BOM 版本。如果您的项目同时包含红帽构建的 Quarkus 和上游 BOM,则此问题可能会导致 Quarkus 和上游 BOM 组合不兼容。
update 命令示例
$ mvn com.redhat.quarkus.platform:quarkus-maven-plugin:3.20.0.redhat-00002:update -Dmaven.repo.local=<path-to-local-repo>
有问题的 pom.xml
文件示例
<properties>
<quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
<quarkus.platform.group-id>com.redhat.quarkus.platform</quarkus.platform.group-id>
<quarkus.platform.version>3.20.0.redhat-00002</quarkus.platform.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>${quarkus.platform.group-id}</groupId>
<artifactId>${quarkus.platform.artifact-id}</artifactId>
<version>${quarkus.platform.version}</version>
</dependency>
<dependency>
<groupId>io.quarkus.platform</groupId>
<artifactId>quarkus-amazon-services-bom</artifactId>
<version>3.2.12.Final</version> 1
</dependency>
</dependencies>
</dependencyManagement>
- 1
- 没有更新版本。
临时解决方案:手动更新版本号。
如需更多信息,请参阅 QUARKUS-5185。
1.8.7. RSA 密码初始化会在原生模式下触发 NPE,并启用了 mandrel-for-jdk-21-rhel8:23.1 和 FIPS
在 Red Hat build of Quarkus 3.20 中,使用 quarkus/mandrel-for-jdk-21-rhel8:23.1
红帽构建的 Quarkus Native Builder 镜像在启用了 FIPS 的环境中的原生模式中初始化 RSA 密码会生成 NullPointerException
(NPE)错误。
这个问题只在启用了 FIPS 的原生模式下发生,它不会影响禁用 FIPS 的原生模式。在启用了 FIPS 的 Red Hat build 时,它也不会影响 JVM 模式。
启用 FIPS 的环境中不支持原生模式。
错误信息示例
2024-10-17 10:45:01,931 ERROR [io.qua.ver.htt.run.QuarkusErrorHandler] (executor-thread-1) HTTP Request to /repro failed, error id: 9b1f5dbb-058b-4c9b-9377-f3acc0a6cba5-1: java.lang.RuntimeException: java.lang.NullPointerException at org.acme.ReproResource.init(ReproResource.java:38) ...
临时解决方案:
如果存在,从
application.properties
文件中删除以下属性:quarkus.security.security-providers=SunPKCS11
在
application.properties
文件中添加以下属性,以在运行时初始化ReproResource
类:quarkus.native.additional-build-args=--initialize-at-run-time=org.acme.ReproResource
如需更多信息,请参阅 MANDREL-245。
1.8.8. Websocket 下一步:在打开事件异常时不会递增连接错误指标
在带有 websocket-next
扩展的 Quarkus 3.20 中,当 @WebSocket
端点在 @OnOpen
生命周期方法中抛出异常时,以下指标不会递增:
-
quarkus_websockets_server_connections_opened_errors_total{uri=${ENDPOINT}}
-
quarkus_websockets_client_connections_opened_errors_total{uri=${ENDPOINT}}
这个行为会影响服务器端和客户端 WebSocket 连接指标。
临时解决方案:目前还没有可用的临时解决方案。计划在以后的发行版本中解决这个问题。
如需更多信息,请参阅 QUARKUS-5977。
1.8.9. Websocket 下一步:默认序列化无法在原生模式下工作
在红帽构建的 Quarkus 3.20 中,当在原生模式下使用 websocket-next
扩展构建和运行应用程序时,WebSocket 消息的默认序列化机制会在不使用自定义 codec 的情况下使用 @OnTextMessage
生命周期回调时失败。
此问题会影响依赖默认 JsonTextMessageCodec
进行序列化和取消序列化 WebSocket 消息的应用程序。如果使用 @OnTextMessage (codec = MyCodec.class)
注释指定自定义 codec,则应用可以正常工作。
临时解决方案:使用 @RegisterForReflection
注释。如需更多信息,请参阅 Quarkus "Tips for writing native application" 指南中的 Registering for reflection 部分。
如需更多信息,请参阅 QUARKUS-5981。