CORB 作业：处理 ServerConnectionException：对等方重置连接答案

【问题标题】：CORB Job : Handle ServerConnectionException: Connection reset by peerCORB 作业：处理 ServerConnectionException：对等方重置连接
【发布时间】：2015-01-30 07:14:29
【问题描述】：

我正在尝试执行 CORB 作业来处理我的文档。但它在处理整个集合的一部分后抛出了以下异常。

com.marklogic.xcc.exceptions.ServerConnectionException: Connection reset by peer
 [Session: user=<username>, cb={default} [ContentSource: <username>, cb={none} [provider: address=<xyz.com>/<IP>, pool=0/64]]]
 [Client: XCC/7.0-2, Server: XDBC/7.0-3.1]
        at com.marklogic.xcc.impl.handlers.AbstractRequestController.runRequest(AbstractRequestController.java:124)
        at com.marklogic.xcc.impl.SessionImpl.submitRequestInternal(SessionImpl.java:388)
        at com.marklogic.xcc.impl.SessionImpl.submitRequest(SessionImpl.java:371)
        at com.marklogic.developer.corb.Transform.call(Transform.java:68)
        at com.marklogic.developer.corb.Transform.call(Transform.java:1)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)

我们尝试增加线程数和内存分配，但无济于事。

我的要求有两个：

这可能是什么根本原因？有没有办法解决这个问题？
如果没有，是否有办法在 shell 脚本中捕获此异常，即执行相同的操作？

【问题讨论】：

MarkLogic ErrorLog.txt 中有什么内容？
当您“尝试增加线程数和内存分配”时，您究竟做了什么？

标签： java linux bash marklogic marklogic-corb

【解决方案1】：

有很多可能的原因。例如，它可能是 JVM 垃圾收集、服务器上的问题，甚至是网络路径中的问题。盲目地改变事情可能没有帮助：首先找出问题，然后纠正它。

最常见的是 JVM 和 GC。 MarkLogic XCC 实现了自己的keepalive 机制，类似于HTTP 1.1 keepalive。如果垃圾收集花费太多时间，这可能会导致超时和重置。在错误发生之前，尝试监视 JVM 是否似乎正在运行其内存分配并频繁地进行垃圾收集。添加-verbosegc 也可能有助于检测到这一点。如果您认为 GC 是问题所在，请尝试添加 -Xincgc。您可能还想减少线程数，以减少内存压力。您还可以使用-Xmx 增加分配。但是不要盲目这样做，我不会超过 1-GiB。

一定要检查ErrorLog.txt 并检查一般的服务器运行状况。它是否使用任何交换空间？是分页吗？操作系统日志中有什么可疑之处吗？出现问题时 CPU、内存、磁盘和网络 I/O 的表现如何？

每隔一段时间，这种东西就会变成防火墙或路由器，它们不喜欢长期连接并关闭它们。如果可能，请安排它，使您的客户端和服务器位于同一子网中，除了一个相对笨拙的集线器或交换机之外，没有其他任何东西。如果任一主机上都有本地防火墙，请确保它不会干扰。

【讨论】：

垃圾收集不会通过网络到达并告诉对端重置连接。
否，但是 GC 会导致 JVM 冻结足够长的时间以致连接保持活动超时。然后当 JVM 再次尝试使用它时，服务器会发送一个重置，因为不再建立连接。
这也不是真的。 Java 不发送保活计时器。 TCP 堆栈在内核内部进行。因此冻结 JVM 不可能有这种效果。也有 18 年没有看到 JVM GC 冻结了。而且您还声称这是“最常见的”原因：您是否有证据支持这一说法？
啊，但是这个 Java 应用程序可以。 CorB 使用 MarkLogic XCC 与服务器通信。 MarkLogic XCC 实现了类似于 HTTP 1.1 keepalive 的东西，这与 TCP/IP keepalive 不同。是的，我对 MarkLogic、XCC 和这类问题有一定的经验。
@mblakele ......我确实将分配减少到不到 1 GiB......并且还添加了选项 -XX+UseMarkConcSweep: 以禁用套接字池。虽然我没有收到任何错误，但我不确定这是否是问题的解决方案。

【解决方案2】：

“对等连接”的可能原因有几个：

对等应用程序故意重置连接。
当其套接字接收缓冲区中仍有未读数据时，对等应用程序关闭了连接。
对等应用程序关闭了连接，之后您继续发送数据。
中间防火墙断开连接，通常是因为超时。

...而且可能还有更多。最常见的原因是 (3)，这是某人的应用程序协议错误。

【讨论】：