HandlerSubscriber is racy (at least as used from RxJava)

[slandelle]

I've been trying to hunt down a race condition that happens in AHC on Travis (can't reproduce locally).

AHC uses RxJava (2.1.7) as a reactive streams implementation for tests.

From io.reactivex.internal.subscribers.StrictSubscriber#onSubscribe:

actual.onSubscribe(this);
SubscriptionHelper.deferredSetOnce(this.s, requested, s);

HandlerSubscriber#onSubscribe schedule provideSubscription to be executed from the channel's EventLoop, that will trigger requesting the subscription. But SubscriptionHelper.deferredSetOnce can also request the subscription. As a consequence, we might be requesting the Publisher concurrently from multiple threads (the calling thread and the event loop one), which causes chunks to be written out of order.

I have no idea if it's a RxJava bug, or if StrictPublisher behaves according to the spec.

cc @jroper

[slandelle]

I have this solution on my side: AsyncHttpClient/async-http-client@391b4d8

I don't know if the issue is related to RxJava's reactive streams implementation and if it would also happen with Akka.

[jroper]

I have no idea what RxJava is doing here, but the subscription passed to onSubscribe on a subscriber is a private contract between that subscriber and what passed it to it. So if something jumps in the middle, and captures the subscription, and starts playing with it itself, that's completely illegal according to the spec. So, if SubscriptionHelper.defferedSetOnce does invoke request, but then forwards onNext provided elements on to the subscriber without checking whether the subscriber it's forwarding to itself has invoked request, that's a bug.