You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some actions are not interruptible. Since Schedulers.io() reuses threads after unsubscribe, a previous uninterruptible action might block execution of new actions, causing unexpected delays or in some cases, deadlocks.
@akarnokd A concrete example is in the test case that I added in #4231, but in general any task that is carelessly written (swallows InterruptedException, or busy looping, etc.) will trigger this issue.
Example:
int numClients = 0;
for (Server s : servers) {
try {
numClients += s.queryNumClients();
} catch (Exception e) {
// Assume 0 clients
}
}
return numClients;
The InterruptedException caused by unsubscribe() is swallowed and if the next s.queryNumClients() blocks for minutes, then this will block the thread for minutes.
What's worse is that this may even come from 3rd party code that also uses Schedulers.io() and cause extremely hard to debug problems.
I see. I'd consider the fix in #4231 as a temporary workaround because such tasks will keep blocking out threads (and leak resources). Generally, this is what newThread() is handy for: you get a new thread that can be blocked without the fear of reuse. Send such untrustwothy tasks to newThread() and the rest to io().
Absolutely, #4231 only prevents other tasks from being blocked by the misbehaving task, it does't prevent the thread (and potentially other resource) leaks.
I believe the thread leak would be present with newThread() as well and there is not much we can do about this. There is Thread.stop() but it introduces more problems than it solves. Hopefully the misbehaving task will complete eventually and at that point the resources will be freed up. If it never completes then it's a lost thread and the resources are leaked permanently.
I happened to face this bug today, was using RxJava 1.1.2. After half an hour of debugging went to check for newer version, and guess what - first bug fix in release notes is exactly the one I was fighting. Pulled latest, everything works like a charm. Thank you guys!
Activity
CachedThreadScheduler should wait until the previous action (if any) …
akarnokd commentedon Jul 23, 2016
Could you give an example of such non-interruptible blocking tasks?
csabakos-zz commentedon Jul 23, 2016
@akarnokd A concrete example is in the test case that I added in #4231, but in general any task that is carelessly written (swallows
InterruptedException, or busy looping, etc.) will trigger this issue.Example:
The
InterruptedExceptioncaused byunsubscribe()is swallowed and if the nexts.queryNumClients()blocks for minutes, then this will block the thread for minutes.What's worse is that this may even come from 3rd party code that also uses
Schedulers.io()and cause extremely hard to debug problems.akarnokd commentedon Jul 23, 2016
I see. I'd consider the fix in #4231 as a temporary workaround because such tasks will keep blocking out threads (and leak resources). Generally, this is what
newThread()is handy for: you get a new thread that can be blocked without the fear of reuse. Send such untrustwothy tasks to newThread() and the rest to io().csabakos-zz commentedon Jul 23, 2016
Absolutely, #4231 only prevents other tasks from being blocked by the misbehaving task, it does't prevent the thread (and potentially other resource) leaks.
I believe the thread leak would be present with
newThread()as well and there is not much we can do about this. There isThread.stop()but it introduces more problems than it solves. Hopefully the misbehaving task will complete eventually and at that point the resources will be freed up. If it never completes then it's a lost thread and the resources are leaked permanently.CachedThreadScheduler should wait until the previous action (if any) … (
Armaxis commentedon Aug 18, 2016
I happened to face this bug today, was using RxJava 1.1.2. After half an hour of debugging went to check for newer version, and guess what - first bug fix in release notes is exactly the one I was fighting. Pulled latest, everything works like a charm. Thank you guys!