Croway opened a new pull request, #9264: URL: https://github.com/apache/camel-quarkus/pull/9264
_Claude Code on behalf of Croway_ Camel Quarkus side of [CAMEL-25197](https://issues.apache.org/jira/browse/CAMEL-25197). **Depends on apache/camel#27210** (the `CliWebSocketClient` SPI of `camel-cli-connector`): draft until it is merged and in a Camel 4.23.0-SNAPSHOT. With `camel.cli.transport=websocket`, the Camel CLI connector dials out to a developer tool over a WebSocket. This makes it use the Quarkus WebSockets Next client when the application already has `quarkus-websockets-next`, and the JDK client otherwise. No dependency is added to the application for this. ## Changes - `QuarkusCliWebSocketClient` (runtime): implements `CliWebSocketClient` with `BasicWebSocketConnector`. Callbacks are non-blocking on the event loop (the transport parses and sends on its own threads), messages up to 16 MB, the handshake rejections are mapped to their HTTP status, the url path and query are sent as given. - `CliConnectorProcessor`: registers the client bean only when the `io.quarkus.websockets.next` capability is present; `quarkus-websockets-next` is an `<optional>` dependency of the runtime module. No new build-time option. `camel.cli.websocket.client=jdk` (Camel) forces the JDK client. - New runtime option `quarkus.camel.cli.websocket.tls-configuration-name`: TLS configuration from the Quarkus TLS registry for `wss://`. - Docs: `usage.adoc` for the WebSocket transport and the client selection. Workarounds for WebSockets Next (Quarkus 3.40.1), both documented in the code: - Its client back-pressure (new in 3.40) fetches one frame per message received, so a connection receiving messages in several frames (over 64 KB) eventually stops reading. The extension defaults `quarkus.websockets-next.client.max-pending-messages` to `0` (as before 3.40) when `quarkus-websockets-next` is present; this applies to the other WebSockets Next clients of the application too, unless the property is set (documented). - When a connection is lost without a close frame (status 1006), it fails creating the `CloseReason` for `onClose` and skips releasing the connection: the client registers no `onClose`, the transport detects the closed connection on its next send or by its heartbeat. - Frames stay at 64 KB (the Vert.x default): Vert.x uses the same size to split what it sends, and servers commonly refuse larger frames. ## Tests - `integration-tests-jvm/cli-connector` (JDK client) and the new `integration-tests-jvm/cli-connector-websockets-next` (same application and tests via `build-helper`, with `quarkus-websockets-next`): an in-test WebSocket tool server, `hello` reports the expected client, actions, large messages both ways (4 MB actions, trace snapshots over 64 KB frames), the HTTP 401 handshake reported and recovered from, encoded query parameters sent as given. 4 tests each, green (3 consecutive runs). - `extensions-jvm/cli-connector/deployment`: existing tests green. - Soak test (240 s; 5 Camel Main apps, 1 Camel Quarkus app with the JDK client, 1 with the WebSockets Next client; the tool closing connections, a network blackhole, the tool down, the token rejected): PASS, all apps recovered from every disruption, no unexpected errors, all exited on the `stop` action. Native: the extension stays JVM-only. The WebSockets Next client itself needs no reflection and supports native, so it would not block native support; the rest of `camel-cli-connector` was not assessed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
