[concurrency-interest] Upcoming jdk9 j.u.c JEP

Viktor Klang viktor.klang at gmail.com
Mon Jul 27 04:26:22 EDT 2015


Note that since it is a spec for async, the invocation of onNext (called a
signal in the spec) is divorced from the processing of said signal.

Let's keep the discussion in the aforementioned Issue, to avoid confusion.

On Fri, Jul 24, 2015 at 11:59 PM, Greg Wilkins <gregw at webtide.com> wrote:

>
> Doug,
>
> Note that the specification
> <https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/README.md#specification>
> says that onNext should not throw an exception:
>
> *"the only legal way for a Subscriber to signal failure is by cancelling
> its Subscription"*
>
> However it also specifies what to do if that rule is broken:
>
>
> *In the case that this rule is violated, any associated Subscription to
> the Subscriber MUST be considered as cancelled, and the caller MUST raise
> this error condition in a fashion that is adequate for the runtime
> environment*
>
> So as there is no other legal outlet for failures in a subscriber, I'm
> guessing that lots of implementations will just throw unchecked exceptions
> from onNext (no point catching them if you have nothing you can do with
> them) and SubmissionPublisher needs to be able to deal with it....   which
> it currently does by feeding the exception back downstream by calling
> onError(Throwable)
>
> I would think that it should call cancel() and then notify with a callback
> like you suggest (or perhaps the default onSubscriberException
> implementation should be cancel?).
>
> So yes, I think the impl needs to be improved in this regards, but I also
> think this is a good example how not having a proper outlet for subscriber
> failures in the spec has confused an implementation.... but I'll take that
> discussion back to the issue.
>
> cheers
>
>
>
>
>
>
>
>
>
>
> On 25 July 2015 at 06:26, Doug Lea <dl at cs.oswego.edu> wrote:
>
>>
>> I've been encouraging people to discuss spec issues at
>>   https://github.com/reactive-streams/reactive-streams-jvm/issues
>> just to keep them in one place.
>>
>> But this one might impact SubmissionPublisher (a potential j.u.c
>> class, not the spec itself):
>>
>>
>> On 07/23/2015 06:35 PM, Greg Wilkins wrote:
>>
>>  Specifically that it is asymmetric and an error in the
>>> middle of a chain of processors can be propagated downstream with
>>> onError(Throwable) but can only be propagated upstream with cancel().
>>>
>>>
>> If a call to onNext throws an exception, the only thing guaranteed
>> is that the subscription will be cancelled. (There are also some
>> words saying that the Subscriber is at that point non-compliant.)
>> But I don't see anything that stops any publisher/subscription
>> from doing something with that exception before/during the
>> cancellation. So should there be a SubmissionPublisher method
>> along the lines of:
>>
>>   onSubscriberException(Consumer<? extends Throwable> handler);
>>
>>
>> -Doug
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150727/ae16efd3/attachment.html>


More information about the Concurrency-interest mailing list