细节
-
类型:
错误
-
状态: Resolved
A developer had implemented a fix and is waiting for a feedback from the reporter.">解决 (查看工作流） -
优先级:
至关重要的
-
解决方法: 固定
-
环境:必威国际有限公司Jenkins版本2.223 -从docker容器Jenkins / Jenkins:centos构建
至关重要的-
类似的问题:
-
发布:必威国际有限公司詹金斯2.229
描述
如果来自管道步骤的响应大于64kb, Websocket连接将失败。
重建问题的步骤:
- 使用dock必威国际有限公司er容器jenkins/jenkins:centos运行jenkins服务器
- 创建一个启用webSocket的新节点
- 在另一台Linux虚拟机/从机上，运行带有-webSocket选项的agent.jar连接到Jenkins Master必威国际有限公司
- 创建一个带有输出文本>64kb步骤的管道。例如，创建一个大小为> 64Kb的文本文件。'cat'文件作为管道步骤。
管道{代理{标签“test-channelclose”}阶段{阶段(的调试问题) {steps {sh“猫build_output.log”/ / archiveArtifacts“build_output.log”} } } }
5.运行管道将中断并出现以下错误。
詹金斯探员。必威国际有限公司WebSocketAgents$Session error警告:null org.eclipse.jetty.websocket.api.MessageTooLargeException:在org.eclipse.jetty.websocket.api.WebSocketPolicy.assertValidBinaryMessageSize(WebSocketPolicy.java:128) at org.eclipse.jetty. websocket.commoner . assertsanepayloadlength (Parser.java:133) at org.eclipse.jetty. websocket.commoner . parseframe (Parser.java:494) at org.eclipse.jetty. websocket.commoner . parsesingleframe (Parser.java:253) at org.eclipse.jetty. api. websocketpolicy . assertbinarymessagesize (WebSocketPolicy.java:128at org.eclipse.jetty.io.abstractwebsocketconnection . onfillable (AbstractWebSocketConnection.java:441) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at org.eclipse.jetty.java:441at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) at org.eclipse.jetty.util.thread. reservedthreadadexecutor $ReservedThread.run(reservedthreadadexecutor .java:388) atorg.eclipse.jetty.util.thread.QueuedThreadPool. runjob (QueuedThreadPool.java:806) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938) at java.lang.Thread.run(Thread.java:748)
注意:一种解决方法是将输出写入文件并存档该文件。然而，并不是所有的管道步骤都支持将输出写入文件的简单方法。
附件
问题的链接
- 涉及到
-
- Resolved
A developer had implemented a fix and is waiting for a feedback from the reporter.">解决
-
- Open
The issue is open and ready for the assignee to start work on it.">开放
- 链接
活动
奥利弗贡德人ž一吉普车-222是一个非常重要的特性。即使它是实验性的，我们也应该为LTS用户修复它，这样我们就可以从早期采用率那里获得更多的采纳和反馈。
对我来说，回移植4,3是一个不可行的选择，因为删除了不赞成的代码https://github.com/必威国际有限公司jenkinsci/remoting/pull/369．此更改还添加了串行版本id，如果通过Remoting通道串行化类，则可能导致有趣的行为。我建议即使在2.222.3中也不要冒险。CCRaihaan Shouhell谁提交了一个补丁。
与此同时https://github.com/必威国际有限公司jenkinsci/remoting/pull/373如果它作为Remoting 4.2.1发布，那么对于2.222.2/3将是相当大的。由于Remoting引擎下的补丁(JNLP4可能会受到变化的潜在影响)，这仍然是一个高风险的更改，但我个人会尝试2.222.2，假设大量的补丁测试是对JNLP4模式的性能。
由于Remoting引擎下的补丁，这仍然是一个高风险的更改(JNLP4可能会受到更改的潜在影响)。
我看不出是怎么回事。类中使用的特定于websocket的处理程序方法之外没有受影响的代码websocket2.222中的新模式。X，除了一个新方法AbstractByteBufferCommandTransport这是新修改的代码。
我同意杰西的观点。我不认为为了更好地支持WebSockets而进行的更改会对之前已有的功能造成任何风险。
我正在准备4.2.1补丁，其中只包含4.2之上的WebSockets补丁。这就消除了任何对https://github.com/必威国际有限公司jenkinsci/remoting/pull/369．
杰夫•汤普森补充了评论:我同意杰西的观点。我不认为为了更好地支持WebSockets而进行的更改会对之前已有的功能造成任何风险。我正在准备4.2.1补丁，其中只包含4.2之上的WebSockets补丁。这消除了对https://github.com/jenkinsci/remoting/pull/369的必威国际有限公司任何担忧。Remoting 4.2.1版本已经发布，可以在repo.jenkins.io中获得。必威国际有限公司发行说明见https://github.com/必威国际有限公司jenkinsci/remoting/releases/tag/remoting-4.2.1．我将该版本整合到2.222中。在x LTS必威国际有限公司詹金斯分支https://github.com/必威国际有限公司jenkinsci/jenkins/pull/4635．
杰夫•汤普森补充了评论:Remoting 4.2.1版本已经发布，可以在repo.jenkins.io中获得。必威国际有限公司发布说明在https://github.com/jenkinsci/remoting/r必威国际有限公司eleases/tag/remoting-4.2.1。我将该版本整合到2.222中。在x LTS必威国际有限公司詹金斯分支https://github.com/必威国际有限公司jenkinsci/jenkins/pull/4635．
杰西•格里克，杰夫•汤普森，我选择不支持它，主要是因为它太新了。由于不相关的更改远没有修复的主体那么可怕，我建议针对2.222.3，不需要特别的远程发布。
注意:这也需要反向移植https://github.com/必威国际有限公司jenkinsci/jenkins/pull/4601