[SPARK-13398][STREAMING] Move away from thread pool task support to forkjoin #11423
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… that is the number of objects kept in memory.
…upport-java-forkjoin
|
Test build #52165 has finished for PR 11423 at commit
|
|
The HiveComptability test seems likely unrelated (happened in another unrelated PR at the same time). Will double check in the morning. |
| /** | ||
| * Extend ForkJoinWorkerThread so we can instantiate it. | ||
| */ | ||
| class SparkForkJoinWorkerThread(pool: ForkJoinPool) extends ForkJoinWorkerThread(pool) { |
There was a problem hiding this comment.
Comments are great of course -- javadoc won't do anything here. It could be a line comment.
I think you might be able to collapse most of this with anonymous classes:
val factory = new ForkJoinWorkerThreadFactory {
override def newThread(pool: ForkJoinPool) =
new ForkJoinWorkerThread(pool) {
setName(prefix + "-" + super.getName)
}
}
|
Test build #52201 has finished for PR 11423 at commit
|
|
Jenkins, retest this please |
|
Test build #52239 has finished for PR 11423 at commit
|
|
I'll just switch this to use the Scala one for now (this code path does the correct thing in 2.12 but in 2.11 using the Java pool also reports system parallelism). |
….11 necessary for correct concurrency report)
…upport-java-forkjoin
holdenk
changed the title
|
Test build #52420 has finished for PR 11423 at commit
|
|
LGTM |
|
Merged to master |
roygao94
pushed a commit
to roygao94/spark
that referenced
this pull request
Mar 22, 2016
…orkjoin ## What changes were proposed in this pull request? Remove old deprecated ThreadPoolExecutor and replace with ExecutionContext using a ForkJoinPool. The downside of this is that scala's ForkJoinPool doesn't give us a way to specify the thread pool name (and is a wrapper of Java's in 2.12) except by providing a custom factory. Note that we can't use Java's ForkJoinPool directly in Scala 2.11 since it uses a ExecutionContext which reports system parallelism. One other implicit change that happens is the old ExecutionContext would have reported a different default parallelism since it used system parallelism rather than threadpool parallelism (this was likely not intended but also likely not a huge difference). The previous version of this PR attempted to use an execution context constructed on the ThreadPool (but not the deprecated ThreadPoolExecutor class) so as to keep the ability to have human readable named threads but this reported system parallelism. ## How was this patch tested? unit tests: streaming/testOnly org.apache.spark.streaming.util.* Author: Holden Karau <holden@us.ibm.com> Closes apache#11423 from holdenk/SPARK-13398-move-away-from-ThreadPoolTaskSupport-java-forkjoin.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
Remove old deprecated ThreadPoolExecutor and replace with ExecutionContext using a ForkJoinPool. The downside of this is that scala's ForkJoinPool doesn't give us a way to specify the thread pool name (and is a wrapper of Java's in 2.12) except by providing a custom factory. Note that we can't use Java's ForkJoinPool directly in Scala 2.11 since it uses a ExecutionContext which reports system parallelism. One other implicit change that happens is the old ExecutionContext would have reported a different default parallelism since it used system parallelism rather than threadpool parallelism (this was likely not intended but also likely not a huge difference).
The previous version of this PR attempted to use an execution context constructed on the ThreadPool (but not the deprecated ThreadPoolExecutor class) so as to keep the ability to have human readable named threads but this reported system parallelism.
How was this patch tested?
unit tests: streaming/testOnly org.apache.spark.streaming.util.*