Thread running otherSingleSource of a timeout is interrupted before running

[janbols]

Hi, I'm running io.reactivex.rxjava2:rxjava:2.0.6 .

When doing the following, the thread running the otherSingleSource has its interrupted flag set. This throws java.lang.InterruptedExceptions. Below, you can find an example:

Single.timer(3, TimeUnit.SECONDS)
                .timeout(1, TimeUnit.SECONDS, Single.fromCallable { return Long.MAX_VALUE })
                .blockingGet()

The thread that runs return Long.MAX_VALUE is interrupted. You can find a unit test using spock on https://gist.github.com/janbols/e97ceb349641f58895379ff562aab59b

The same effect is observed when we call timeout with an explicit scheduler. The only way I could make this working is by subscribing the otherSingleSource on another thread like the following:

Single.timer(3, TimeUnit.SECONDS)
                .timeout(1, TimeUnit.SECONDS, Single.fromCallable { return Long.MAX_VALUE }).subscribeOn(io())
                .blockingGet()

I tried to debug the code and I think it has something to do with the call to set.clear() inside the runnable when the timer expires in io.reactivex.internal.operators.single.SingleTimeout#subscribeActual. At that time set contains the timer disposable and by clearing it, you're also interrupting the thread that's running the task in io.reactivex.internal.schedulers.ScheduledRunnable#dispose.

Of course I could be completely wrong as well since thread scheduling isn't really my cup of tea :-).

[akarnokd]

Hi. It is possible but I can't really read Groovy/Spock code. The resolution could be to remove the set and have the individual Disposables there. PR welcome (also check of Maybe is needed as well).

[gaganis]

Hi @janbols, I have tried running your Spock speck in a fresh project with just a dependency to io.reactivex.rxjava2:rxjava:2.0.6 and it did not fail.

This is weird, and the only thing that you might be running something before this spec that might impact this. Could you provide more info?

[akarnokd]

PR #5207 should resolve this case as well.

[janbols]

Excellent. Indeed that would solve it. Thanks

[janbols]

Hi @gaganis , yes indeed the test succeeds. That's intentional because the feature methods indicating the bug are annotated with FailsWith. They will start failing once the bug is fixed, indicating that the annotation can be removed.

Best regards
Jan

[gaganis]

I am new to spock so I missed that! Thanks @janbols for the clarification!

[akarnokd]

@janbols RxJava 2.0.8 has been released with fixes to the schedulers. Could you verify the issue is resolved for you?

[janbols]

Hi @akarnokd ,
commenting out the FailsWith annotation on my unit tests, made them pass. In spock-speak this means the bug is fixed indeed.

Thanks for all the work. I'll close the issue.