В моей компании сейчас используется версия Jenkins 2.204.2. И у нас много рабов. Один из подчиненных, который работает как служба на Windows машине, часто отключается. В качестве обходного решения мы перезапускаем сервис, и он снова подключается, но это решение действительно раздражает. Журнал вывода при отключении агента выглядит следующим образом:
Соединение разорвано: java .nio.channels.ClosedChannelException at org.jenkinsci.remoting.protocol.impl.ChannelApplicationLayer.onReadClosed (ChannelApplicationLayer. java: 209) в org.jenkinsci.remoting.protocol.ApplicationLayer.onRecvClosed (ApplicationLayer. java: 221) в org.jenkinsci.remoting.protocol.ProtocolStack $ Ptr.onRecvClosed (ProtocolStack. java: 816) в org.jenkinsci.remoting.protocol.FilterLayer.onRecvClosed (FilterLayer. java: 287) в org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.onRecvClosed (SSLEngineFilterLayer. javaremj.jpg1: 18): 18) .protocol.impl.SSLEngineFilterLayer.switchToNoSecure (SSLEngineFilterLayer. java: 283) в org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.processWrite (SSLEngineFilterLayer. * 10ci. .SSLEngineFilterLayer.processQueuedWrites (SSLEngineFilterLayer. java: 248) в org.jenkinsci.remoting.protoco l.impl.SSLEngineFilterLayer.doSend (SSLEngineFilterLayer. java: 200) по адресу org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.doCloseSend (SSLEngineFilterLayer. java: 21jp. Ptr.doCloseSend (ProtocolStack. java: 784) по адресу org.jenkinsci.remoting.protocol.ApplicationLayer.doCloseWrite (ApplicationLayer. java: 172) по адресу org.jenkinsci.remoting.protocol.impl.ChannelApplicationLayer $omtransport (ByteButeport) ChannelApplicationLayer. java: 314) в hudson.remoting.Channel.close (Channel. java: 1450) в hudson.remoting.Channel.close (Channel. java: 1403) в hudson.slaves.SlaveComputer.closeChannel (SlaveComputer. java: 843) в hudson.slaves.SlaveComputer.access $ 100 (SlaveComputer. java: 108) в hudson.slaves.SlaveComputer $ 2.run (SlaveComputer. java: 734) в jenkins.util. ContextResettingExecutorService $ 1.run (ContextResettingExecutorService. java: 28) в jenkins.security.ImpersonatingExecutorService $ 1.run (ImpersonatingExecutorService. java: 59) в java .util.concurrent.Executors $ RunnableAdapter.call (Executors. java: 511) в java .util.concurrent.FutureTask.run (FutureTask. java: 266) в java .util. concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor. java: 1149) в java .util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor. java: 624) в java .lang.Thread.run (поток. java: 748)
Я ищу постоянное решение, но мне трудно разобраться в проблеме. На самом деле я не знаю, где я должен искать (не знаю, проверять ли я логи Дженкинса или java версию или что-то еще). Не могли бы вы помочь мне об этой проблеме? Любая помощь будет высоко оценена, спасибо заранее.
Выводы команды java -version , на ведущем устройстве которой CentOS 7, как показано ниже
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot (TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
на подчиненном, который Windows Сервер 2019
Picked up _JAVA_OPTIONS: -Xmx256M
java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)