Hi Pavel, Ondrej, et. al.,
I agree with you both that the complexity is a result of the statefulness introduced. And that it is inherent. I don’t think the current spec is an additional burden, it’s just that adding the ‘broadcast layer’ is a PITA. But like you said, I already have that. Thanks for all the feedback!
Groeten,
Friso
Van: Ondrej Mihályi
Verzonden: donderdag 9 maart 2017 14:03
Aan: users_at_jax-rs-spec.java.net
Onderwerp: [jax-rs-spec users] Re: Server Sent Events
I agree with Pavel, the SseEventSink has to be stateful as it binds to a particular connection. There is not way to initiate an SSE connection from the server - the browser needs to open it and then listen for events. That's how SSE events are designed, and not only in JAX-RS, but on the HTTP spec level. Any layer that would support clustering would need to be supplied, I don't see a need to standardize this, it should be enough that it is possible and sufficiently straightforward with the current API.
If the warning comes from Eclipse and not from the runtime, it's OK. Some IDEs try to be very explicit to let you now you MIGHT be doing something wrong, but they obviously don't know the use case. From the stateful nature of SSE, it has to be bound to a connection and therefore it is perfectly OK to leave it open and store it away into a map. The warning just informs you that you should ensure that the object is closed later, which is obvious. You also have to care about releasing the objects which were closed automatically when a connection is terminated, ie. handle all error scenarios gracefully.
Pavel, I believe that we have a callback for connection closed event, don't we? In that callback, one should ensure that all the references to the SseEventSink are released. I'm sorry, I'm not able to open the API docs now to check if the callback is available.
Ondrej
2017-03-09 11:24 GMT+01:00 Pavel Bucek <pavel.bucek_at_oracle.com>:
Hi Friso,
its still the same as it used to be with Jersey, so .. I don't really understand what do you perceive as additional burden.
In clustered environments, you'll need to know which SseEventSink belongs to which server. You can't send an event from different cluster node, since there is no open connection from the client to any other node that the one which originally accepted the connection. What you'd most likely need is to build another layer, which would "broadcast" across cluster members and then individual member will broadcast that to connected clients. It might be more complicated when you need to find single client, but still doable. Open connection represents a state, which is not transferrable by design and I'm not sure what we could do to make this situation better.
I have to emphasize that there is nothing extra you need to do compared to your original code. And if there is, maybe I still don't understand what that is..
Best regards,
Pavel