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

From: Pavel Bucek <>
Date: Thu, 16 Feb 2017 16:30:28 +0100

Hi Andrey,

thanks for your feedback.

Thanks for bringing this up, since I am really struggling with this API.
Not saying I don't like current proposal, but I don't like to force
users to call any method starting with "on*".

It is not only about #onComplete() vs #close(). Originally, there was a
method called #write, which could be implemented as default method and
only call #onNext(OutboundSseEvent). The problem is that #onComplete()
must be there because of Subscriber contract, so it won and #write was

Having #close might seem redundant, same pattern as with #write and
#onNext. It provides the option to use SseEventSink in try with
resources block. Which might not be enough to justify the method. Also,
we currently have #isClosed.. but that can be renamed to #isCompleted..

I believe we will have similar issues in NIO, we will have to deal with
them sooner or later. Ultimately, it will be done during the "purge of
flow.*". But if you have anything to add now, please do :)

Best regards,

On 15/02/17 23:28, Andrey Redko wrote:
> Hi Pavel,
> My apologies for hijacking experts group but thanks a lot for the
> revisiting and updating SSE API part of the JAX-RS specification.
> Personally, I think it looks much better, modern and aligned with the
> reactive paradigm which industry is moving towards. One particular
> concern I would like to bring up is related to SseEventSink API,
> particularly regarding *close()* method. As SseEventSink is
> Flow.Subscriber at the same time, there is a conflict between
> *close()* and *onComplete()* methods. Typically, *Flow.Subscriber* has
> a following lifecycle:
> subscriber.onNext(...)
> subscriber.onNext(...)
> subscriber.onNext(...)
> *subscriber.onComplete()* *<---- We are done here*
> While the current examples do that:
> subscriber.onNext(...)
> subscriber.onNext(...)
> subscriber.onNext(...)
> *subscriber.close()* *<---- We are done here*
> **
> I think this duality on implementation level could be solved, but on
> API level it might cause confusion: what should be called,
> *onComplete()*? *close()*? both? Taking into account the
> Flow.Publisher <-> Flow.Subscription <-> Flow.Subscriber, there is
> only *onComplete* method which will be called as part of the
> processing. Does it make sense to simplify SseEventSink API by
> removing the close() method as it will be fully replaceable by
> *onComplete*?
> Thank you very much.
> Best Regards,
> Andriy Redko