Skip to content

[JENKINS-68933] Update to Jetty 10, with WebSocket - #6785

Closed
jglick wants to merge 29 commits into
jenkinsci:masterfrom
jglick:ws-JENKINS-68933-jetty-10
Closed

[JENKINS-68933] Update to Jetty 10, with WebSocket#6785
jglick wants to merge 29 commits into
jenkinsci:masterfrom
jglick:ws-JENKINS-68933-jetty-10

Conversation

@jglick

@jglick jglick commented Jul 5, 2022

Copy link
Copy Markdown
Member

Subsumes #6780; reverts #6781, reapplying #6694.

See JENKINS-68933.

Development loop:

mvnd -Pquick-build install -pl websocket/spi,websocket/jetty9,websocket/jetty10,core,war
mvnd -pl test test -Dtest=JNLPLauncherRealTest\#webSocket

Proposed changelog entries

  • Upgrading the bundled Jetty to version 10, via Winstone 6.0.

Proposed upgrade guidelines

N/A

Maintainer checklist

Before the changes are marked as ready-for-merge:

  • There are at least 2 approvals for the pull request and no outstanding requests for change
  • Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
  • Changelog entries in the PR title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood
  • Proper changelog labels are set so that the changelog can be generated automatically
  • If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
  • If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

Comment thread websocket/jetty10/src/main/java/jenkins/websocket/Jetty10Provider.java Outdated

@basil basil left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was exploring this logic earlier today and came to a similar conclusion about isUpgradeRequest. I had been thinking about inlining it, but I guess retaining only the first check as you did here is probably good enough.

This looks good pending a few remaining tasks:

  • Merge in the static analysis fixes I just made to #6780 because otherwise this won't build in CI
  • Probably need to add Enforcer excludes for the new modules as well to get Enforcer to pass on the war/ module
  • Add the call to JettyWebSocketServletContainerInitializer.configure in Winstone per #6785 (comment)
  • Once the CI build is passing, I would personally like to run another build with the Jetty 10 based JenkinsRule from jenkinsci/jenkins-test-harness#453 and PCT/BOM testing with the same. It should not turn up anything new, but I would rather be safe than sorry. With passing core and BOM/PCT suites with a Jetty 10 based JenkinsRule I would feel very confident about this change.

Happy to help with these tasks, so let me know how we can best drive this forward together.

@jglick

jglick commented Jul 6, 2022

Copy link
Copy Markdown
Member Author

help with these tasks

I think the first three are now covered, so in principle this PR should now be ready as far as WebSocket support is concerned as soon as the Winstone change is released. If you want to set up a separate draft PR for testing against jenkinsci/jenkins-test-harness#453 that would certainly increase our confidence.

(There are apparently other regressions like #6694 (comment) and #6694 (comment) which could be addressed as well. I was not planning to look into those, so if you want to look into them, it may make more sense to file a fresh PR subsuming this one which is truly production-ready. My interest was in restoring WS functionality, especially since I was responsible for the reflection tech debt that made it tricky to understand where Jetty 10 was not working; I guess it did not even occur to me at the time that Jetty would change their APIs incompatibly.)

@jglick

jglick commented Jul 6, 2022

Copy link
Copy Markdown
Member Author

Interactively verified wsecho/ (in both text and binary modes, incl. ping visible after 30s with websocat -vv); Pipeline builds on a WS agent; CLI in -webSocket mode.

Otherwise closing connections sometimes produces stack traces

```
WARNING	j.websocket.WebSocketSession#error: unhandled WebSocket service error
java.nio.channels.ClosedChannelException
	at org.eclipse.jetty.websocket.core.internal.WebSocketSessionState.onEof(WebSocketSessionState.java:169)
	at org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession.onEof(WebSocketCoreSession.java:253)
	at org.eclipse.jetty.websocket.core.internal.WebSocketConnection.fillAndParse(WebSocketConnection.java:482)
	at org.eclipse.jetty.websocket.core.internal.WebSocketConnection.onFillable(WebSocketConnection.java:340)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:319)
	at …
```

or

```
WARNING	j.agents.WebSocketAgents$Session#error
java.nio.channels.ClosedChannelException
	at org.eclipse.jetty.websocket.core.internal.WebSocketSessionState.onEof(WebSocketSessionState.java:169)
	at org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession.onEof(WebSocketCoreSession.java:253)
	at …
```

though I am not sure if that is actually new behavior.
jglick added 4 commits July 6, 2022 12:59
Otherwise closing connections sometimes produces stack traces

```
WARNING	j.websocket.WebSocketSession#error: unhandled WebSocket service error
java.nio.channels.ClosedChannelException
	at org.eclipse.jetty.websocket.core.internal.WebSocketSessionState.onEof(WebSocketSessionState.java:169)
	at org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession.onEof(WebSocketCoreSession.java:253)
	at org.eclipse.jetty.websocket.core.internal.WebSocketConnection.fillAndParse(WebSocketConnection.java:482)
	at org.eclipse.jetty.websocket.core.internal.WebSocketConnection.onFillable(WebSocketConnection.java:340)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:319)
	at …
```

or

```
WARNING	j.agents.WebSocketAgents$Session#error
java.nio.channels.ClosedChannelException
	at org.eclipse.jetty.websocket.core.internal.WebSocketSessionState.onEof(WebSocketSessionState.java:169)
	at org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession.onEof(WebSocketCoreSession.java:253)
	at …
```

though I am not sure if that is actually new behavior.
@jglick

jglick commented Jul 6, 2022

Copy link
Copy Markdown
Member Author

FYI I was topologically merging in the upstream branch, which Git tracks better than cherry-picks. (Until you squash-merge the upstream PR. One reason I prefer to use true merges.)

@basil basil left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was not planning to look into those, so if you want to look into them, it may make more sense to file a fresh PR subsuming this one which is truly production-ready.

Sure, let's get a green CI build for #6785 and let's get #6780 merged and then I can file a new PR for the final reintegration. Many thanks for the collaboration thus far. I plan to do two sets of core PRs (one with regular test harness and one with Jetty 10 test harness) and two corresponding BOM/PCT runs.

Comment thread war/pom.xml
@github-actions github-actions Bot added the unresolved-merge-conflict There is a merge conflict with the target branch. label Jul 7, 2022
@github-actions

github-actions Bot commented Jul 7, 2022

Copy link
Copy Markdown
Contributor

Please take a moment and address the merge conflicts of your pull request. Thanks!

@basil

basil commented Jul 7, 2022

Copy link
Copy Markdown
Member

Continuing in #6801

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants