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 <mailto:pavel.bucek_at_oracle.com>
> *Verzonden: *donderdag 9 maart 2017 08:21
> *Aan: *users_at_jax-rs-spec.java.net <mailto: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,
>