[jax-rs-spec users] Re: Server Sent Events

From: Pavel Bucek <>
Date: Thu, 9 Mar 2017 14:40:31 +0100

Hi Ondrej,

(responding to the question in the last paragraph)

We do have a callback like that on SseBroadcaster. The SseEventSink
doesn't have it, it throws an IllegalStateException from any method
(other than close() and isClosed()) when it is already closed.

We did hit this during implementing the latest draft and I believe this
should be enough; having said that, if anyone thinks that we do require
to add possibility to register such callback directly to the
SseEventSink, please file an issue.

Thanks and regards,

On 09/03/2017 14:03, Ondrej Mihályi wrote:
> 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 <
> <>>:
> 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
> On 09/03/2017 10:53,
> <> wrote:
>> Hi Pavel,
>> Thanks for the feedback. I really meant process. Our flow is like
>> this:
>> 1. The user visits a site and starts listening for SSE
>> 2. The site sends the user to an app on their phone
>> 3. The user does something in the app and sends the result to
>> the app’s server
>> 4. The app’s server invokes the callback URI
>> 5. An event is sent to the user
>> The managing of the SseEventSink now becomes quite the burden,
>> especially if you factor in that the callback may happen on
>> another server in the cluster. In my gist I used a Map, but that
>> will obviously not work in a more complex environment.
>> Groeten,
>> Friso
>> *Van: *Pavel Bucek <>
>> *Verzonden: *donderdag 9 maart 2017 08:21
>> *Aan: * <>
>> *Onderwerp: *[jax-rs-spec users] Re: Server Sent Events
>> Hi Friso,
>> the example in JAX-RS and your case is the same.
>> We are using executor service to show that it IS possible to
>> send/store SseEventSink instances and work with them from another
>> Thread.
>> Having said that, your case is ok and will work as it does now.
>> The only thing is (and I believe that is just a "typo" on your
>> side) is that it must be different Thread, not a Process, as is
>> mentioned in the code snippet you've presented.
>> Best regards,