Hi Alessio,
the method in your question is just another variant of:
http://download.java.net/java/jdk9/docs/api/java/util/concurrent/Flow.Publisher.html#subscribe-java.util.concurrent.Flow.Subscriber-
The subscription is meant to work same as
Subscriber#onSubscribe(Subscription). I wanted to say that when using
this variant of subscribe method, there is a back-pressure support and
the subscriber can control how many messages will be received. (as long
as there is long enough buffer, depends on the inflow). It is NOT meant
to influence other subscribers, only callbacks registered "together" in
the single #subscribe(...) invocation.
Does it make more sense?
I plan to re-read the javadoc and make it more clear, this is obviously
the first adept to improve.
Thanks and regards,
Pavel
On 15/02/2017 18:26, Alessio Soldano wrote:
> Il 15/02/2017 16:47, Pavel Bucek ha scritto:
>> Dear experts,
>>
>> if you have any feedback for SSE, please provide it by the end of
>> this week, sooner the better.
> I've just finished updating my prototype implementation to the latest
> API and still have to try some non-trivial test scenario, which will
> hopefully allow for providing meaningful feedback. In the mean time,
> something (possibly minor) I've noticed is that SseEventSource defines
> the following method:
>
> void subscribe(Consumer<SseSubscription> onSubscribe,
> Consumer<InboundSseEvent> onEvent,
> Consumer<Throwable> onError,
> Runnable onComplete);
>
> now, can you clarify how the onSubscribe parameter is really meant to
> be used? (the javadoc mentions it wrt invocations to SseSubscription'
> request(long) and cancel() methods affecting registered handlers..?).
>
> Thanks
> Alessio