Sidecar application used by Confluent for VS Code, as a local proxy for Confluent Cloud, Confluent Platform and local Kafka clusters, to help users build streaming applications.
At the moment, the endpoints GET /gateway/v1/connections and GET /gateway/v1/connections/:id (implicitly) call DirectConnectionState#getConnectionStatus(), which synchronously checks the status of the connection. This can become problematic and lead to high request execution times, at least for the endpoint GET /gateway/v1/connections when users manage multiple direct connections.
Proposal
We should migrate to asynchronously checking the statuses of connections in a background thread, similar to how we refresh tokens of Confluent Cloud connections. This would allow the endpoints GET /gateway/v1/connections and GET /gateway/v1/connections/:id to instantly return the most recent status of each connection without having to interact with other/remote systems.
We should make the interval used for checking the connection statuses configurable. It probably makes sense to have one configuration property for each connection type. Initially, we can set the different intervals to the same value, e.g., 5 seconds.
The status field of Connections should expose when the status has been determined.
rhauch
commented
4 days ago
Status Quo
At the moment, the endpoints
GET /gateway/v1/connectionsandGET /gateway/v1/connections/:id(implicitly) call DirectConnectionState#getConnectionStatus(), which synchronously checks the status of the connection. This can become problematic and lead to high request execution times, at least for the endpointGET /gateway/v1/connectionswhen users manage multiple direct connections.Proposal
We should migrate to asynchronously checking the statuses of connections in a background thread, similar to how we refresh tokens of Confluent Cloud connections. This would allow the endpoints
GET /gateway/v1/connectionsandGET /gateway/v1/connections/:idto instantly return the most recent status of each connection without having to interact with other/remote systems.We should make the interval used for checking the connection statuses configurable. It probably makes sense to have one configuration property for each connection type. Initially, we can set the different intervals to the same value, e.g., 5 seconds.
The
statusfield of Connections should expose when the status has been determined.