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
>
> On 09/03/2017 10:53, vrolijken_at_yahoo.com 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 <pavel.bucek_at_oracle.com>
> *Verzonden: *donderdag 9 maart 2017 08:21
> *Aan: *users_at_jax-rs-spec.java.net
> *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,
>
>
>
>
>
>
>