主页 / server / 问题

问题[java](server)

Martin Hope
Amadeusz Liu
Asked: 2024-05-05 12:53:38 +0800 CST
  • 6

我在 Windows 上运行一个 java 应用程序，但由于高峰流量，它偶尔会每月崩溃一次。更糟糕的是，每次崩溃时 JVM 都会自动生成内存转储并快速占用磁盘空间。是否有任何 JVM 参数/或任何其他方法来阻止它生成完整内存转储，因为我不需要这么多转储？

java
Martin Hope
SegmentationFault
Asked: 2024-03-08 03:59:48 +0800 CST
  • 5

当我尝试使用表单上传文档时，出现以下错误：

org.apache.commons.fileupload.FileUploadBase$IOFileUploadException：处理多部分/表单数据请求失败。/temp/upload_37a45ff5_18dcebe4760__7ff4_00000073.tmp（没有这样的文件或目录）

它在 ServletFileUpload.parseRequest(request) 上失败，但堆栈跟踪没有提供其他信息。这似乎只发生在大于 100kB 的文件中。

该目录存在并且可读可写，并且有足够的可用磁盘空间。我尝试增加 server.xml 中的最大文件大小，更新所有必要的 web.xml 文件以匹配此限制，并更新 conf 目录中的连接器 maxPostSize - 没有效果。

我正在使用 HTML 表单提交将请求从客户端发送到服务器。

仅当我在 Mac 或基于 Linux 的系统上运行 Tomcat 8 时才会发生此错误 - 如果我在 Windows 上运行它，一切都会按预期工作。我还通过运行全新安装的 Tomcat 8.5.78 进行了尝试。最后，我还尝试将 commons.fileupload 包从 1.2.1 更新到 1.5——所有这些更改对结果没有影响。

我完全迷失了，希望能得到关于我能做什么的指示，或者至少调试问题的最佳方法是什么。谢谢！

java
Martin Hope
Scream
Asked: 2024-02-01 03:03:00 +0800 CST
  • 5

今天注意到我的 Payara5 服务器日志下方的错误消息，由于 Glassfish 最近非常流行，我花了一些时间来找出该怎么办。

[2024-01-31T16:44:11.325+0000] [Payara 5.2022.5] [WARNING] [NCLS-SECURITY-05054] [javax.enterprise.system.security.ssl] [tid: _ThreadID=18107 _ThreadName=admin-thread-pool::admin-listener(25)] [timeMillis: 1706719451325] [levelValue: 900] [[
  The SSL certificate has expired: [
[
  Version: V3
  Subject: OU=Trustis FPS Root CA, O=Trustis Limited, C=GB
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

  Key:  Sun RSA public key, 2048 bits
  params: null
  modulus: 24908633667180321967674873268814531635547921938344065146546904438489502673823487510936146573960061486273718694334781317348708908262947651303078579882700224692570831312368945979170373153648052597761950956395913615810736512525962630740585310636521594672085066580175665043758918430925599500808969653476864564698808991702431004110644739915567322643581281788777374680963817281333282843028696667329131753328247995199072853681672136148214770992098772732734082912115629981882473191620546572069699037050136366328673247895507219755706167110912566425482228784709797122932080366498493920541761658523188072646247208026589367964269
  public exponent: 65537
  Validity: [From: Tue Dec 23 12:14:06 UTC 2003,
               To: Sun Jan 21 11:36:54 UTC 2024]
  Issuer: OU=Trustis FPS Root CA, O=Trustis Limited, C=GB
  SerialNumber: [    1b1fadb6 20f924d3 366bf7c7 f18ca059]

Certificate Extensions: 3
[1]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: BA FA 71 25 79 8B 57 41   25 21 86 0B 71 EB B2 64  ..q%y.WA%!..q..d
0010: 0E 8B 21 67                                        ..!g
]
]

[2]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

[3]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: BA FA 71 25 79 8B 57 41   25 21 86 0B 71 EB B2 64  ..q%y.WA%!..q..d
0010: 0E 8B 21 67                                        ..!g
]
]

]
  Algorithm: [SHA1withRSA]
  Signature:
0000: 7E 58 FF FD 35 19 7D 9C   18 4F 9E B0 2B BC 8E 8C  .X..5....O..+...
0010: 14 FF 2C A0 DA 47 5B C3   EF 81 2D AF 05 EA 74 48  ..,..G[...-...tH
0020: 5B F3 3E 4E 07 C7 6D C5   B3 93 CF 22 35 5C B6 3F  [.>N..m...."5\.?
0030: 75 27 5F 09 96 CD A0 FE   BE 40 0C 5C 12 55 F8 93  u'_......@.\.U..
0040: 82 CA 29 E9 5E 3F 56 57   8B 38 36 F7 45 1A 4C 28  ..).^?VW.86.E.L(
0050: CD 9E 41 B8 ED 56 4C 84   A4 40 C8 B8 B0 A5 2B 69  ..A..VL..@....+i
0060: 70 04 6A C3 F8 D4 12 32   F9 0E C3 B1 DC 32 84 44  p.j....2.....2.D
0070: 2C 6F CB 46 0F EA 66 41   0F 4F F1 58 A5 A6 0D 0D  ,o.F..fA.O.X....
0080: 0F 61 DE A5 9E 5D 7D 65   A1 3C 17 E7 A8 55 4E EF  .a...].e.<...UN.
0090: A0 C7 ED C6 44 7F 54 F5   A3 E0 8F F0 7C 55 22 8F  ....D.T......U".
00A0: 29 B6 81 A3 E1 6D 4E 2C   1B 80 67 EC AD 20 9F 0C  )....mN,..g.. ..
00B0: 62 61 D5 97 FF 43 ED 2D   C1 DA 5D 29 2A 85 3F AC  ba...C.-..])*.?.
00C0: 65 EE 86 0F 05 8D 90 5F   DF EE 9F F4 BF EE 1D FB  e......_........
00D0: 98 E4 7F 90 2B 84 78 10   0E 6C 49 53 EF 15 5B 65  ....+.x..lIS..[e
00E0: 46 4A 5D AF BA FB 3A 72   1D CD F6 25 88 1E 97 CC  FJ]...:r...%....
00F0: 21 9C 29 01 0D 65 EB 57   D9 F3 57 96 BB 48 CD 81  !.)..e.W..W..H..

]]]
java
Martin Hope
barnyard9
Asked: 2023-12-24 13:14:28 +0800 CST
  • 5

重新创建的步骤

  • pkill -f glassfish。

  • pkill -9 java。

  • 重复几次以确保万无一失。

  • ps-aux| grep 'glassfish_domain_name/config'

它显示它正在从 root 用户运行。所有域都会自动从 root 用户运行

  • 再次终止该使用kill -9 pid并对所有域执行此操作。

  • 几分钟后它会自动从 root 启动。

  • 当我通过 root 或通过旨在运行它的特定用户列出域时，它显示“域未运行”。

服务运行得几乎很好，但这个奇怪的问题让我很烦恼。有任何帮助调试这个场景吗？

好吧，是 monit 在做这个

java
Martin Hope
Epsilon
Asked: 2023-01-08 18:38:46 +0800 CST
  • 5

请注意，在我更新证书之前，整个集群都运行良好。我在使用 Elasticsearch 7.5。

我使用 certificate-util 更新了我的证书 - 创建了一个包含我所有服务器和 Kibana 节点的 server.yml，使用 -pem、-multiple 和 --keep-ca-key 运行该实用程序，传递了 ca.crt以及发送给节点的各种节点证书，确保 elasticsearch.yml 和 kibana.yml 文件适当地指向它们，并进行滚动重启。然后一切都崩溃了。

主要问题——我目前至少遇到的问题——是我在主题中遇到了错误。完整的，来自与之通信的 Elastic 节点的日志：

io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:473) ~[netty-codec-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:281) ~[netty-codec-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1422) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:931) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:700) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:600) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:554) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:514) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1050) [netty-common-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.43.Final.jar:4.1.43.Final]
        at java.lang.Thread.run(Thread.java:830) [?:?]
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
        at sun.security.ssl.Alert.createSSLException(Alert.java:131) ~[?:?]
        at sun.security.ssl.TransportContext.fatal(TransportContext.java:324) ~[?:?]
        at sun.security.ssl.TransportContext.fatal(TransportContext.java:267) ~[?:?]
        at sun.security.ssl.TransportContext.fatal(TransportContext.java:262) ~[?:?]
        at sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkClientCerts(CertificateMessage.java:1275) ~[?:?]
        at sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1178) ~[?:?]
        at sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1159) ~[?:?]
        at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396) ~[?:?]
        at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1260) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1247) ~[?:?]
        at java.security.AccessController.doPrivileged(AccessController.java:691) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1192) ~[?:?]
        at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1502) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1516) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1400) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1227) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1274) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:503) ~[netty-codec-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442) ~[netty-codec-4.1.43.Final.jar:4.1.43.Final]
        ... 16 more
Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
        at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:349) ~[?:?]
        at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:258) ~[?:?]
        at sun.security.validator.Validator.validate(Validator.java:264) ~[?:?]
        at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:285) ~[?:?]
        at sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:138) ~[?:?]
        at sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkClientCerts(CertificateMessage.java:1253) ~[?:?]
        at sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1178) ~[?:?]
        at sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1159) ~[?:?]
        at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396) ~[?:?]
        at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1260) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1247) ~[?:?]
        at java.security.AccessController.doPrivileged(AccessController.java:691) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1192) ~[?:?]
        at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1502) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1516) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1400) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1227) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1274) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:503) ~[netty-codec-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442) ~[netty-codec-4.1.43.Final.jar:4.1.43.Final]
        ... 16 more
Caused by: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
        at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:158) ~[?:?]
        at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:84) ~[?:?]
        at java.security.cert.CertPathValidator.validate(CertPathValidator.java:309) ~[?:?]
        at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:344) ~[?:?]
        at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:258) ~[?:?]
        at sun.security.validator.Validator.validate(Validator.java:264) ~[?:?]
        at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:285) ~[?:?]
        at sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:138) ~[?:?]
        at sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkClientCerts(CertificateMessage.java:1253) ~[?:?]
        at sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1178) ~[?:?]
        at sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1159) ~[?:?]
        at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396) ~[?:?]
        at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1260) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1247) ~[?:?]
        at java.security.AccessController.doPrivileged(AccessController.java:691) ~[?:?]
        at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1192) ~[?:?]
        at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1502) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1516) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1400) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1227) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1274) ~[netty-handler-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:503) ~[netty-codec-4.1.43.Final.jar:4.1.43.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442) ~[netty-codec-4.1.43.Final.jar:4.1.43.Final]
        ... 16 more

我所有的节点都给出了类似的错误。

从表面上看，它看起来相当简单 - 你会认为 ca.crt 在 Kibana 节点上是错误的（至少，这是我从搜索中发现的。）如果它是错误的，我不知道为什么 - 它实际上是与我在所有其他节点上获得的 ca.crt 相同。

据我所知，我没有明确配置密钥库，elasticsearch-keystore 的输出如下所示：

[root@Kibana Node kibana]# /usr/share/elasticsearch/bin/elasticsearch-keystore list
bootstrap.password
keystore.seed
xpack.security.authc.realms.active_directory.platform_ad.secure_bind_password

如果 Java 有一个密钥库，我也找不到它，至少找不到名称“keystore”——如果有人知道可以在哪里配置它，下一步可能会很好。

我不确定我还能做些什么来解决问题 - 我的 Google-fu 让我失望了（我发现的一切都指向 CA 确实是问题，以最简单的方式 - 它们不匹配。如果在这种情况下它们不匹配，这是证书实用程序的错误，但将它们与 openssl 进行比较并没有发现任何差异。）

快速总结：用于为集群生成所有证书的同一个 ca.crt 在 Kibana 上似乎不受信任，但似乎在其他节点上工作。

java
Martin Hope
user1933738
Asked: 2022-03-17 05:03:26 +0800 CST
  • 0

我运行一个基于 Java 的 CMS，它将缓存的图像放在 WEB-INF 文件夹中，特别是在 /WEB-INF/imagecache/. 不幸的是，这个目录变得非常大，有很多嵌套路径，并且 Tomcat 重新启动变得非常缓慢 - 将日志级别设置为org.apache.jasper.servlet.TldScanner.levelFINE 说明了原因，有大量这样的消息：

16-Mar-2022 13:50:56.109 FINE [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanResourcePaths No TLD files were found in resource path [/WEB-INF/imagecache/<snip>/].

有没有办法完全禁止特定目录中的 TldScanner？

tomcat java tomcat8
Martin Hope
Kurru
Asked: 2022-02-28 23:36:13 +0800 CST
  • 2

我正在尝试将 xargs 安装在运行 openjdk:17-oracle 的容器中，但我无法确定此映像中存在什么包管理器。

FROM openjdk:17-oracle
RUN apt-get install findutils

抛出错误：

 => ERROR [stage-1 4/4] RUN apt-get install findutils                                                                      0.5s
------
 > [stage-1 4/4] RUN apt-get install findutils:
#13 0.395 /bin/sh: apt-get: command not found
-

yum install findutils和其他几个一样。

我需要 xargs，因为 gradle runner 使用它来为我的 java 进程构建“执行”命令。

java oracle-linux containers
Martin Hope
acgbox
Asked: 2022-02-10 06:50:27 +0800 CST
  • 0

我需要禁用java.security 文件（java 8 SE）中的以下行：

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
   include jdk.disabled.namedCurves

在窗户里

Windows 中的图像。

窗口路径：Program Files\Java\jre1.8.0_301\lib\security\java.security

禁用这些行的目的是避免出现以下错误消息：

Error: javax.net.ssl.SSLHandshakeException: No appropriate protocol 
(protocol is disabled or cipher suites are inappropriate)

以及此处发布的解决方案提案（即对这些行发表评论）。

我不确定在行首 (#) 是否会禁用这两个操作系统的注释。因为这个oracle文档说是//

无论哪个用于注释行，我也不知道是否有必要注释掉所有 3 行，或者只是注释掉第一行禁用所有 3。示例：

这边走：

# jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
   include jdk.disabled.namedCurves

还是那样？

# jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
#   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
#   include jdk.disabled.namedCurves

问题：

如何在 Windows 和 Linux 上注释掉（禁用）java.security文件中的前几行以避免“错误：javax.net.ssl.SSLHandshakeException”，或者有人向我解释是否有另一种解决方案，不同于已发布的解决方案

windows java linux
Martin Hope
Cabbage Parachute
Asked: 2021-12-24 06:04:54 +0800 CST
  • 3

我在 RHEL 8 服务器上安装了支持 log4j2 ( http://home.apache.org/~dongjin/post/apache-kafka-log4j2-support/ ) 的 Kafka 3.0 预览版。Kafka 和 Zookeeper 作为 systemd 用户服务成功运行。我在 systemd 单元文件中设置了环境变量KAFKA_LOG4J_OPTS="-Dlog4j.configurationFile=file:/home/username/kafka/bin/../config/log4j2.properties"，以便使用 log4j 2.17。

但是，有一件奇怪的事情：所有 log4j 日志都存储在一个目录中，该目录实际上称为${kafka.logs.dir}主目录。垃圾收集器成功地将日志存储在正确的日志位置~/kafka/logs。所以这个目录~/kafka/logs包含了类似的文件kafkaServer-gc.log.0.current，而奇怪的目录~/${kafka.logs.dir}包含server.log,controller.log等等。

在查看 kafka 和 zookeeper 的进程时，我可以看到它们都有参数-Dkafka.logs.dir=/home/username/kafka/bin/../logs。这不应该定义kafka.logs.dir文件中使用的环境变量config/log4j2.properties吗？为什么 Zookeeper 和 Kafka 显然无法访问这个$kafka.logs.dir环境变量？

java systemd log4j kafka rhel8