Verbindungsproblem mit Jenkins-Slave unter Windows Azure

Question

Ich habe einen Jenkins-Slave-Knoten auf einer Windows Azure-VM eingerichtet. Wenn Sie auf diesem Knoten aufbauen, läuft das Projekt ungefähr 20 bis 30 Minuten lang reibungslos, danach wird die Verbindung unterbrochen. Ich war auf der VM des Knotens, als die Verbindung unterbrochen wurde und es scheint, dass sie die Verbindung zum Jenkins Master (auch eine Azure VM) verliert/zurücksetzt. Hat jemand ähnliche Probleme gehabt und konnte es lösen? Die Stapelverfolgung ist wie folgt. Jede Hilfe wäre willkommen.

Fortschritt: | ===================== FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Fehler hudson abzubrechen. remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: fehlgeschlagen bei hudson.remoting.RequestAbortedException.wrapForRethrow (RequestAbortedException.java:41) bei hudson.remoting.RequestAbortedException.wrapForRethrow (RequestAbortedException.java:34 abzutreiben) bei hudson.remoting.Request.call (Request.java:174) bei hudson.remoting.Channel.call (Channel.java:739) bei hudson.remoting.RemoteInvocationHandler.invoke (RemoteInvocationHandler.java:168) bei com.sun.proxy. $ Proxy49.join (Unbekannte Quelle) bei hudson.Launcher $ RemoteLauncher $ ProcImpl.join (Launcher.java:951) bei hudson.tasks.CommandInterpreter.join (CommandInterpreter.java:137) bei hudson.tasks.CommandInterpreter.perform (CommandInterpreter.java:97) bei hudson.tasks.CommandInterpreter.perform (CommandInterpreter.java:66) bei hudson.tasks.BuildStepMonitor $ 1. Führen Sie (BuildStepMonitor.java:20) bei hudson.model.AbstractBuild $ AbstractBuildExecution.perform (AbstractBuild.java:745) bei hudson.model.Build $ BuildExecution.build (Build.java:198) bei hudson.model.Build $ BuildExecution.doRun (Build. java: 159) bei hudson.model.AbstractBuild $ AbstractBuildExecution.run (Abstra ctBuild.java:518) bei hudson.model.Run.execute (Run.java:1709) bei hudson.model.FreeStyleBuild.run (FreeStyleBuild.java:43) bei hudson.model.ResourceController.execute (ResourceController. java: 88) bei hudson.model.Executor.run (Executor.java:231)

verursacht durch: hudson.remoting.RequestAbortedException: java.io.IOException: Fehler bei hudson.remoting.Request abzubrechen. abbrechen (Request.java:299) bei hudson.remoting.Channel.terminate (Channel.java:802) bei hudson.remoting.Channel $ 2.terminate (Channel.java:483) bei hudson.remoting.AbstractByteArrayCommandTransport $ 1. beende (AbstractByteArrayCommandTransport.java:72) bei org.jenkinsci.remoting.nio.NioChannelHub $ NioTransport.abort (NioChannelHub.java:184) bei org.jenkinsci.remoting.nio.NioChannelHub.run (NioChannelHub.java:563) bei jenkins.util.ContextResettingExecutorService 1 $ .run (ContextResettingExecutorService.java:28) bei java.util.concurrent.Executors $ RunnableAdapter.call (Unbekannte Quelle) bei java.util.concurrent.FutureTask $ Sync.innerRun (Unbekannte Quelle) bei java.util.concurrent .FutureTask.run (Unbekannte Quelle) bei java.util.concurrent.ThreadPoolExecutor.runWorker (Unbekannte Quelle) bei java.util.concurrent.ThreadPoolExecutor $ Worker.run (Unbekannte Quelle) bei java.lang.Thread.run (Unbekannte Quelle)

Verursacht durch: java.io.IOException: Fehler abbrechen ... 9 weitere

Verursacht durch: java.io.IOException: Eine bestehende Verbindung wurde von dem Remote-Host bei sun.nio.ch gewaltsam geschlossen .SocketDispatcher.read0 (Native Method) bei sun.nio.ch.SocketDispatcher.read (Unbekannte Quelle) bei sun.nio.ch.IOUtil.readIntoNativeBuffer (Unbekannte Quelle) bei sun.nio.ch.IOUtil.read (Unknown Source) bei sun.nio.ch.SocketChannelImpl.read (Unknown Source) bei org.jenkinsci.remoting.nio.FifoBuffer $ Pointer.receive (FifoBuffer.java:136) bei org.jenkinsci.remoting.nio.FifoBuffer.receive (FifoBuffer.java:306) bei org.jenkinsci.remoting.nio.NioChannelHub.run (NioChannelHub.java:496) ... 7 weitere

Answer 1

ich auch auf Jenkins CI in Azure bin Einstellung und war das gleiche Problem bekommen. Insbesondere würde ich diesen Fehler in dem Slave-Fehlerprotokoll Jenkins sehen:

SEVERE: I/O error in channel channel 
java.net.SocketException: Connection reset 

um es zu umgehen, müssen Sie die Frequenz erhöhen, mit der der Slave den Master Pings. Sie können dazu die Systemeigenschaft Dhudson.slaves.ChannelPinger.pingInterval zu Ihrer Master-Datei jenkins.xml hinzufügen.

Ich änderte es alle 2 Minuten ping und der Kanal war in der Lage, die Verbindung zu halten, ohne sie fallen zu lassen. XML sieht so aus:

<arguments> 
    -Xrs -Xmx256m -Dhudson.slaves.ChannelPinger.pingInterval=2 
    -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle 
    -jar "%BASE%\jenkins.war" 
    --httpPort=8080 
</arguments> 

Für weitere Informationen können Sie the related ticket sehen.

Answer 2

Wenn Sie eine neuere Version von Jenkins (uns ist 1,584), können Sie den Knoten gehen Seite für den Slave konfigurieren, klicken Sie auf die Schaltfläche Erweitert unter Startart, und fügen Sie -Dhudson.slaves.ChannelPinger.pingInterval=2 auf die JVM-Optionen Feld.

Das hat den Trick für uns!