WebSockets Next: fire CDI events for each connection added/removed

[mkouba]

Description

The payload should contain the connection id.

Implementation ideas

No response

[quarkus-bot]

/cc @Ladicek (arc), @manovotn (arc)

[mkouba]

So have several options here. First of all, we should decide if we really want to use CDI events or some other kind of API (listener interface, Vertx eventbus, etc.).

And if we decide to use CDI events, we would need to (A) introduce a special type for each event; e.g. ConnectionOpen/ConnectionClosed and possibly also ClientConnectionOpen/ClientConnectionClosed (the payload would be the identifier assigned to the connection) or (B) introduce open/close qualifiers and reuse the WebSocketConnection and WebSocketClientConnection. We should also decide whether we fire the events synchronously, asynchronously or both.

When I think about it, we could also consider reusing @OnOpen and @OnClose and support global callbacks in a similar way as we support global error handlers, i.e. @OnError declared outside an endpoint... but that could be really confusing 🤔.

[manovotn]

So have several options here. First of all, we should decide if we really want to use CDI events or some other kind of API (listener interface, Vertx eventbus, etc.).

Is there a reason why we shouldn't use CDI events? They seem like a natural fit.

(B) introduce open/close qualifiers and reuse the WebSocketConnection and WebSocketClientConnection.

+1 to this one as it looks simpler.

We should also decide whether we fire the events synchronously, asynchronously or both.

Probably both? If there are no OM for given event, it's pretty cheap anyway.

[mkouba]

So have several options here. First of all, we should decide if we really want to use CDI events or some other kind of API (listener interface, Vertx eventbus, etc.).

Is there a reason why we shouldn't use CDI events? They seem like a natural fit.

(B) introduce open/close qualifiers and reuse the WebSocketConnection and WebSocketClientConnection.

+1 to this one as it looks simpler.

The only downside I can see is that for "close" events the connection object is basically unusable and most of the operations would result in an exception.

We should also decide whether we fire the events synchronously, asynchronously or both.

Probably both? If there are no OM for given event, it's pretty cheap anyway.

My concern with sync observers is that they block the current thread which might be dangerous because we open/close the connection on the event loop.

[manovotn]

The only downside I can see is that for "close" events the connection object is basically unusable and most of the operations would result in an exception.

Yes, at that point it is just a marker payload.

My concern with sync observers is that they block the current thread which might be dangerous because we open/close the connection on the event loop.

Didn't think about that, that's very good point.