Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set removeOnCancelPolicy on the threadpool if supported #1922

Merged

Conversation

akarnokd
Copy link
Member

@akarnokd akarnokd commented Dec 2, 2014

This should solve the task retention problem of unused timeout tasks mentioned in #1919.

I know Java 7+ ScheduledThreadPoolExecutor has the setRemoveOnCancelPolicy and I remember seeing it in Android although I can't tell from which API version.

In Java 6, this can't be solved without rewriting the entire scheduler or using a backported executor.

@daschl
Copy link
Contributor

daschl commented Dec 2, 2014

@akarnokd cool, thanks for whipping this up so quickly. Since RxJava supports Java 6 we need to fix that too, right?

@akarnokd
Copy link
Member Author

akarnokd commented Dec 2, 2014

I looked at the packages of jsr166_ but couldn't find one that ports this flag back to Java 6.

@@ -35,6 +34,19 @@
/* package */
public NewThreadWorker(ThreadFactory threadFactory) {
executor = Executors.newScheduledThreadPool(1, threadFactory);
// Java 7+: cancelled future tasks can be removed from the executor thus avoiding memory leak
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice :-) I was wondering if we could start using reflection for things like this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it is one-time only such as here, then sure.

benjchristensen added a commit that referenced this pull request Dec 9, 2014
Set removeOnCancelPolicy on the threadpool if supported
@benjchristensen benjchristensen merged commit 6620a14 into ReactiveX:1.x Dec 9, 2014
@daschl
Copy link
Contributor

daschl commented Dec 9, 2014

@benjchristensen are there plans to "fix" this for java 6 too? Since we technically support it.. or do we mark it as a limitation and people that are hit by this need to go to java 7? I'm asking because we have lots of users on java 6 and some of the requests have 75s timeouts.

@akarnokd akarnokd deleted the SchedulersRemoveOnCancelPolicy branch December 9, 2014 13:28
@benjchristensen
Copy link
Member

I'm open to a fix that works for Java 6 if someone can suggest what to do and/or submit a PR.

I personally don't have the time to tackle this anytime soon but would accept the change if it solves the problem without breaking anything else (including performance) for Java 7/8.

@daschl
Copy link
Contributor

daschl commented Dec 9, 2014

@benjchristensen okay thanks for the info. I'll tackle it if customers start to "complain", for now I also think its not as high priority - since technically jdk 6 is EOL anyway :)

@benjchristensen
Copy link
Member

Yes :-) The strongest reason actually that RxJava supports Java 6 rather than 7 as the minimum is for Android support.

If it becomes an issue for your customers and you want to tackle this I'll happily review, discuss and merge.

@akarnokd
Copy link
Member Author

akarnokd commented Dec 9, 2014

You'd need to backport the Java 7 ScheduledThreadPoolExecutor and a bunch of helper classes. I looked for a backport on Doug Lea's site but no luck.

@zsxwing
Copy link
Member

zsxwing commented Dec 18, 2014

How about calling ScheduledThreadPoolExecutor.remove(Runnable task) in unsubscribe for Java 6? Although it's a O(n) action, while it's O(log n) in Java 7+, it's better than OOM.

@akarnokd
Copy link
Member Author

That doesn't work on submit() tasks because they are wrapped. Maybe a better option is to have purge() be called periodically.

@zsxwing
Copy link
Member

zsxwing commented Dec 18, 2014

That doesn't work on submit() tasks because they are wrapped.

The returned ScheduledFuture is exactly the object in the workQueue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants