Задание CORB: дескриптор ServerConnectionException: сброс соединения по пиру

Question

Я пытаюсь выполнить задание 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)

Мы попытались увеличить количество потоков и распределение памяти, но безрезультатно.

Мое требование в два раза:

1. Что может быть причиной этого? Есть ли способ решить проблему?

2. Если нет, есть ли способ перехватить это исключение в сценарии оболочки, который выполняет то же самое?

Answer 1

Есть много возможных причин. Например, это может быть сборка мусора JVM, проблема на сервере или даже что-то в сетевом пути. Слепые изменения вряд ли помогут: сначала определите проблему, а затем исправьте ее.

Чаще всего это JVM и GC. В MarkLogic XCC реализован собственный механизм поддержки активности, похожий на HTTP 1.1 keepalive. Если сборка мусора занимает слишком много времени, это может привести к таймаутам и сбросам. Попробуйте выполнить мониторинг, чтобы убедиться, что JVM не работает с выделением памяти и часто выполняет сборку мусора, прежде чем произойдет ошибка. Добавление -verbosegc также может быть полезно обнаружить это. Если вы считаете, что проблема в GC, попробуйте добавить -Xincgc, Вы также можете уменьшить количество потоков, чтобы уменьшить нагрузку на память. Вы также можете увеличить распределение с -Xmx, Но не делайте этого вслепую, и я бы не стал переходить на 1 ГиБ.

Обязательно проверьте ErrorLog.txt а также проверьте общее состояние сервера. Используется ли какое-либо пространство подкачки? Это пейджинг? Что-нибудь подозрительное в логах ОС? Как выглядят процессор, память, диск и сетевой ввод-вывод при возникновении проблемы?

Время от времени такого рода вещи оказываются брандмауэром или маршрутизатором, который не любит долгоживущие соединения и отключает их. Если возможно, организуйте так, чтобы ваш клиент и сервер находились в одной подсети, и между ними не было ничего, кроме относительно тупого концентратора или коммутатора. Если на любом из хостов есть локальный брандмауэр, убедитесь, что он не мешает.

Answer 2

Возможные причины "соединения через одноранговый узел":

1. Одноранговое приложение намеренно сбрасывает соединение.
2. Одноранговое приложение закрыло соединение, пока в его буфере приема сокета еще оставались непрочитанные данные.
3. Одноранговое приложение закрыло соединение, и вы продолжали посылать данные впоследствии.
4. Промежуточный межсетевой экран разорвал соединение, обычно из-за тайм-аута.

... и может быть больше. Наиболее распространенной причиной является (3), которая является ошибкой протокола приложения с чьей-либо стороны.