"Interrupted while waiting for subscription to complete." in 1.0.0-rc8

[edenman]

Doesn't happen on rc7. I can repro 100% of the time. Happens on both KitKat and Lollipop so I don't think it's specific to any particular Android version.

FATAL EXCEPTION: RxCachedThreadScheduler-4
Process: com.mycompany.myapp.development, PID: 4413
java.lang.IllegalStateException: Exception thrown on Scheduler.Worker thread. Add `onError` handling.
        at rx.internal.schedulers.ScheduledAction.run(ScheduledAction.java:50)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422)
        at java.util.concurrent.FutureTask.run(FutureTask.java:237)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:152)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:265)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
        at java.lang.Thread.run(Thread.java:818)
Caused by: rx.exceptions.OnErrorNotImplementedException: Interrupted while waiting for subscription to complete. 
        at rx.Observable$30.onError(Observable.java:7252)
        at rx.observers.SafeSubscriber._onError(SafeSubscriber.java:127)
        at rx.observers.SafeSubscriber.onError(SafeSubscriber.java:96)
        at rx.internal.operators.OperatorMap$1.onError(OperatorMap.java:48)
        at rx.internal.operators.OperatorMap$1.onNext(OperatorMap.java:56)
        at rx.internal.operators.NotificationLite.accept(NotificationLite.java:150)
        at rx.subjects.SubjectSubscriptionManager$SubjectObserver.emitNext(SubjectSubscriptionManager.java:254)
        at rx.subjects.BehaviorSubject.onNext(BehaviorSubject.java:166)
        at rx.Observable$34.onNext(Observable.java:7437)
        at rx.observers.SafeSubscriber.onNext(SafeSubscriber.java:104)
        at rx.internal.operators.OperatorMerge$InnerSubscriber.emit(OperatorMerge.java:610)
        at rx.internal.operators.OperatorMerge$InnerSubscriber.onNext(OperatorMerge.java:536)
        at rx.internal.operators.OperatorSingle$1.onCompleted(OperatorSingle.java:75)
        at rx.internal.operators.OperatorTake$1.onNext(OperatorTake.java:72)
        at rx.internal.operators.OperatorSubscribeOn$1$1$1.onNext(OperatorSubscribeOn.java:76)
        at com.mycompany.servercall.ServerCall$1$1.call(ServerCall.java:56)
        at com.mycompany.servercall.ServerCall$1$1.call(ServerCall.java:47)
        at rx.Observable.unsafeSubscribe(Observable.java:7464)
        at rx.internal.operators.OperatorSubscribeOn$1$1.call(OperatorSubscribeOn.java:62)
        at rx.internal.schedulers.ScheduledAction.run(ScheduledAction.java:45)
        ... 7 more 
Caused by: java.lang.RuntimeException: Interrupted while waiting for subscription to complete. 
        at rx.observables.BlockingObservable.blockForSingle(BlockingObservable.java:474)
        at rx.observables.BlockingObservable.single(BlockingObservable.java:348)
        at com.mycompany.myapp.data.CachedThing.buildCachedThing(CachedThing.java:66)
        at com.mycompany.myapp.data.CachedThing.<init>(CachedThing.java:28)
        at com.mycompany.myapp.data.FilterFunc.call(FilterFunc.java:189)
        at com.mycompany.myapp.data.FilterFunc.call(FilterFunc.java:175)
        at com.mycompany.myapp.data.CachedThing.merge(CachedThing.java:60)
        at com.mycompany.myapp.data.ResponseCache.update(ResponseCache.java:80)
        at com.mycompany.myapp.data.TransformFunc.call(TransformFunc.java:105)
        at com.mycompany.myapp.data.TransformFunc.call(TransformFunc.java:99)
        at com.mycompany.servercall.CallState$3.map(CallState.java:79)
        at com.mycompany.servercall.CallState$9.call(CallState.java:195)
        at com.mycompany.servercall.CallState$9.call(CallState.java:193)
        at rx.internal.operators.OperatorMap$1.onNext(OperatorMap.java:54)
        ... 22 more
Caused by: java.lang.InterruptedException
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1279)
        at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:202)
        at rx.observables.BlockingObservable.blockForSingle(BlockingObservable.java:471)
        ... 35 more
Caused by: rx.exceptions.OnErrorThrowable$OnNextValue: OnError while emitting onNext value: .class 
        at rx.internal.operators.OperatorMap$1.onNext(OperatorMap.java:56)
        ... 22 more

CachedThing.buildCachedThing has this block of code that I think is the culprit:

List<SubThing> subThings = Observable.from(things) //
        .map(transformFunction) //
        .filter(not(isNullFunction)) //
        .distinct() //
        .toList() //
        .toBlocking() //
        .single();

I tried writing a testcase to repro but couldn't get it to fail. I'm guessing there's something broken between the android runtime and rxjava's thread management, but I couldn't get any further than that.

[benjchristensen]

The only thing in rc8 that seems related is this: #1793

[benjchristensen]

I can not replicate with this code:

import java.util.List;

import rx.functions.Func1;

public class Testing {

    public static void main(String... args) {
        List<String> subThings = Observable.range(0, 1000)
                .map(new Func1<Integer, String>() {

                    @Override
                    public String call(Integer i) {
                        return String.valueOf(i + 1);
                    }

                })
                .filter(new Func1<String, Boolean>() {

                    @Override
                    public Boolean call(String t) {
                        return t != null;
                    }

                }) //
                .distinct() //
                .toList() //
                .toBlocking() //
                .single();

        System.out.println(subThings);
    }
}

[benjchristensen]

The code that is being interrupted is this: https://github.com/ReactiveX/RxJava/blob/1.x/src/main/java/rx/observables/BlockingObservable.java#L473

        try {
            latch.await();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new RuntimeException("Interrupted while waiting for subscription to complete.", e);
        }

This means the thread was blocked on the latch waiting for a result but while it was waiting it got interrupted.

I don't know what thread you are doing this on, nor do I know much about Android. If Android is using pools of threads it could perhaps retain the right to interrupt and reclaim threads? I know event loops in some frameworks do that kind of thing if something is blocked in them and new work is scheduled.

RxJava itself does not interrupt threads anywhere (that I'm aware of ... and I can't think of any reason we would) so I'm inclined to suggest looking at what thread you are blocking in and see if Android itself could be interrupting it?

Also, could you move to a model where you don't block and instead compose it all together reactively?

[benjchristensen]

Moving to 1.0.x as it's not obvious yet what is going on here.

[Alexander--]

Encountered this on Jellybean. Code in my Application subclass:

Observable<SomeSharedPreferencesWrapper> prefsPrefetch = Async.start(this::prefetchPrefs);

And later in same class:

return prefsPrefetch.toBlocking().single();

I can't grasp exact circumstances, when issue reproduces itself. At first glance they seem to be random, but happens often enough to make prefetching stuff with RxJava pretty much impossible.

[edenman]

I'm gonna work on putting together a minimal test Android app to try and isolate the issue.

[edenman]

https://dl.dropboxusercontent.com/u/7829307/RxJavaBlockingBug.zip

I wasn't able to repro until I added the PublishSubject layer...maybe the issue is the nested toBlocking() calls?

[benjchristensen]

Does Android ever interrupt a thread based on user or system activity? If so then the toBlocking() will always be vulnerable to interruption since anytime a thread is blocked/waiting it can be interrupted.

Is request.onNext ever being called concurrently, or is it sequentially? I can't tell for sure but it looks okay as it looks like it's only ever the single UI thread that would trigger an onNext. If you intend on calling it concurrently wrap it in a SerializedSubject.

If the UI event listener triggers before ObserveThings.start completes then request may not yet be initialized, or the pipeline may not yet be initialized. It looks like that could be race condition ... but I don't understand how MainActivity works well enough. Is that all on the UI thread, or does a background thread do that and then the setOnClickListener register with the UI thread?

I don't particularly see anything wrong in this code ... though to be more idiomatic I would suggest using the Observable sequence to manipulate the data instead of doing it inside the subscribe. You really should never need to use toBlocking. The only 3 times that is ever intended are:

1. Example code in a main method
2. Unit tests (and even then you should probably use TestSubscribe.awaitTerminalEvent instead)
3. Bridging between a blocking and non-blocking system, such as a Servlet

In this case, instead of doing flatMap.subscribe(all logic here) do something like this instead:

request.flatMap(mapResult)
.map(transformFunction)
.filter(notNull())
.distinct()
.toList()
.subscribe(yourListHere)

This is more idiomatic, doesn't involve creating another Observable and never requires doing the toBlocking stuff.... which is kind of the point of Rx. You should only ever have 1 subscribe at the very end of your flow and it should just be the side-effect, no actual processing in it.

[edenman]

MainActivity all happens on the main thread, as does the onClickHandler.

I've worked around the problem in our app by no longer using toBlocking in our subscribe method, but I still think there might be an Rx bug here. Android shouldn't interrupt unless there's a deadlock of some sort, and I'm afraid the nested toBlocking calls (discouraged though they may be) are causing the thread to stall. Regardless, the workaround is easy, so I don't think this should be a 1.0 blocker. Thanks for looking into it!

[headinthebox]

You should really only ever call to blocking in command line test scripts but never in production code.

If you really need to end up blocking, you may as well push all the blocking backwardsvand write regular synchrounius code.

[headinthebox]

Maybe we should mark toblocking as depricated (forever) such that you get a warning every time you use it.