Merge pull request #74 from rxin/kill

Job cancellation via job group id.

This PR adds a simple API to group together a set of jobs belonging to a thread and threads spawned from it. It also allows the cancellation of all jobs in this group.

An example:

    sc.setJobDescription("this_is_the_group_id", "some job description")
    sc.parallelize(1 to 10000, 2).map { i => Thread.sleep(10); i }.count()

In a separate thread:

    sc.cancelJobGroup("this_is_the_group_id")

(cherry picked from commit 599dcb0ddf740e028cc8faac163303be8f9400a6)
Signed-off-by: Reynold Xin <rxin@apache.org>
Merge pull request #68 from mosharaf/master

Faster and stable/reliable broadcast

HttpBroadcast is noticeably slow, but the alternatives (TreeBroadcast or BitTorrentBroadcast) are notoriously unreliable. The main problem with them is they try to manage the memory for the pieces of a broadcast themselves. Right now, the BroadcastManager does not know which machines the tasks reading from a broadcast variable is running and when they have finished. Consequently, we try to guess and often guess wrong, which blows up the memory usage and kills/hangs jobs.

This very simple implementation solves the problem by not trying to manage the intermediate pieces; instead, it offloads that duty to the BlockManager which is quite good at juggling blocks. Otherwise, it is very similar to the BitTorrentBroadcast implementation (without fancy optimizations). And it runs much faster than HttpBroadcast we have right now.

I've been using this for another project for last couple of weeks, and just today did some benchmarking against the Http one. The following shows the improvements for increasing broadcast size for cold runs. Each line represent the number of receivers.
![fix-bc-first](https://f.cloud.github.com/assets/232966/1349342/ffa149e4-36e7-11e3-9fa6-c74555829356.png)

After the first broadcast is over, i.e., after JVM is wormed up and for HttpBroadcast the server is already running (I think), the following are the improvements for warm runs.
![fix-bc-succ](https://f.cloud.github.com/assets/232966/1349352/5a948bae-36e8-11e3-98ce-34f19ebd33e0.jpg)
The curves are not as nice as the cold runs, but the improvements are obvious, specially for larger broadcasts and more receivers.

Depending on how it goes, we should deprecate and/or remove old TreeBroadcast and BitTorrentBroadcast implementations, and hopefully, SPARK-889 will not be necessary any more.

(cherry picked from commit e5316d0685c41a40e54a064cf271f3d62df6c8e8)
Signed-off-by: Reynold Xin <rxin@apache.org>
Merge pull request #76 from pwendell/master

Clarify compression property.

Clarifies that this governs compression of internal data, not input
data or output data.

(cherry picked from commit f628804c023a44bf7506bdca017d9a895dd7eb32)
Signed-off-by: Reynold Xin <rxin@apache.org>
Added deprecation warning to BitTorrentBroadcast and TreeBroadcast implementations. TorrentBroadcast is replacing them.
Add deprecation warning to unrecognized MASTER urls

Unrecognized MASTER urls will throw an exception rather than be parsed as Mesos URLs
in 0.9. See https://github.com/apache/incubator-spark/pull/71
Merge pull request #79 from aarondav/scdefaults0.8

Add deprecation warning to unrecognized MASTER urls

Unrecognized MASTER urls will throw an exception rather than be parsed as Mesos URLs
in 0.9. See 74737264c4a9b2.
Merge branch 'branch-0.8' of github.com:mosharaf/incubator-spark into branch-0.8

Added deprecation warning to BitTorrentBroadcast and TreeBroadcast

Users should gradually move toward TorrentBroadcast.
Merge pull request #85 from rxin/clean

Moved the top level spark package object from spark to org.apache.spark

This is a pretty annoying documentation bug ...

(cherry picked from commit e4abb75d70aa08377829f635fe6135d94e28f434)
Signed-off-by: Reynold Xin <rxin@apache.org>
Merge pull request #84 from rxin/kill1

Added documentation for setJobGroup. Also some minor cleanup in SparkContext.

(cherry picked from commit 2a7ae1736a9ea4c5dded91ebc34f7a33e93835e6)
Signed-off-by: Reynold Xin <rxin@apache.org>
Merge pull request #89 from rxin/executor

Don't setup the uncaught exception handler in local mode.

This avoids unit test failures for Spark streaming.

    java.util.concurrent.RejectedExecutionException: Task org.apache.spark.streaming.JobManager$JobHandler@38cf728d rejected from java.util.concurrent.ThreadPoolExecutor@3b69a41e[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 14]
	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
	at org.apache.spark.streaming.JobManager.runJob(JobManager.scala:54)
	at org.apache.spark.streaming.Scheduler$$anonfun$generateJobs$2.apply(Scheduler.scala:108)
	at org.apache.spark.streaming.Scheduler$$anonfun$generateJobs$2.apply(Scheduler.scala:108)
	at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:60)
	at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:47)
	at org.apache.spark.streaming.Scheduler.generateJobs(Scheduler.scala:108)
	at org.apache.spark.streaming.Scheduler$$anonfun$1.apply$mcVJ$sp(Scheduler.scala:41)
	at org.apache.spark.streaming.util.RecurringTimer.org$apache$spark$streaming$util$RecurringTimer$$loop(RecurringTimer.scala:66)
	at org.apache.spark.streaming.util.RecurringTimer$$anon$1.run(RecurringTimer.scala:34)

(cherry picked from commit 5b9380e0173b3d3d13235ae912e9ccc2a974b98b)
Signed-off-by: Reynold Xin <rxin@apache.org>
Merge pull request #41 from pwendell/shuffle-benchmark

Provide Instrumentation for Shuffle Write Performance

Shuffle write performance can have a major impact on the performance of jobs. This patch adds a few pieces of instrumentation related to shuffle writes. They are:

1. A listing of the time spent performing blocking writes for each task. This is implemented by keeping track of the aggregate delay seen by many individual writes.
2. An undocumented option `spark.shuffle.sync` which forces shuffle data to sync to disk. This is necessary for measuring shuffle performance in the absence of the OS buffer cache.
3. An internal utility which micro-benchmarks write throughput for simulated shuffle outputs.

I'm going to do some performance testing on this to see whether these small timing calls add overhead. From a feature perspective, however, I consider this complete. Any feedback is appreciated.
(cherry picked from commit 35886f347466b25625d5391c97c2deb8293ebc66)

Signed-off-by: Patrick Wendell <pwendell@gmail.com>
Merge pull request #88 from rxin/clean

Made the following traits/interfaces/classes non-public:

Made the following traits/interfaces/classes non-public:
SparkHadoopWriter
SparkHadoopMapRedUtil
SparkHadoopMapReduceUtil
SparkHadoopUtil
PythonAccumulatorParam
BlockManagerSlaveActor
(cherry picked from commit aa61bfd39962a3e3c8ba8e4bcf25f48212933cce)

Signed-off-by: Patrick Wendell <pwendell@gmail.com>
Merge pull request #94 from aarondav/mesos-fix

Fix mesos urls

This was a bug I introduced in https://github.com/apache/incubator-spark/pull/71.
Previously, we explicitly removed the mesos:// part; with #71, this no longer occurs.

(cherry picked from commit 39d2e9b293768b6eeb291313ee94f3e02a0ad522)
Signed-off-by: Reynold Xin <rxin@apache.org>
Revert "Merge pull request #94 from aarondav/mesos-fix"

This reverts commit fe974ba1484dbe6fffdae8680b3b37b26de83145.

The commit only applies to 0.9, not 0.8.x.
Merge pull request #87 from aarondav/shuffle-base

Basic shuffle file consolidation

The Spark shuffle phase can produce a large number of files, as one file is created
per mapper per reducer. For large or repeated jobs, this often produces millions of
shuffle files, which sees extremely degredaded performance from the OS file system.
This patch seeks to reduce that burden by combining multipe shuffle files into one.

This PR draws upon the work of @jason-dai in https://github.com/mesos/spark/pull/669.
However, it simplifies the design in order to get the majority of the gain with less
overall intellectual and code burden. The vast majority of code in this pull request
is a refactor to allow the insertion of a clean layer of indirection between logical
block ids and physical files. This, I feel, provides some design clarity in addition
to enabling shuffle file consolidation.

The main goal is to produce one shuffle file per reducer per active mapper thread.
This allows us to isolate the mappers (simplifying the failure modes), while still
allowing us to reduce the number of mappers tremendously for large tasks. In order
to accomplish this, we simply create a new set of shuffle files for every parallel
task, and return the files to a pool which will be given out to the next run task.

I have run some ad hoc query testing on 5 m1.xlarge EC2 nodes with 2g of executor memory and the following microbenchmark:

    scala> val nums = sc.parallelize(1 to 1000, 1000).flatMap(x => (1 to 1e6.toInt))
    scala> def time(x: => Unit) = { val now = System.currentTimeMillis; x; System.currentTimeMillis - now }
    scala> (1 to 8).map(_ => time(nums.map(x => (x % 100000, 2000, x)).reduceByKey(_ + _).count) / 1000.0)

For this particular workload, with 1000 mappers and 2000 reducers, I saw the old method running at around 15 minutes, with the consolidated shuffle files running at around 4 minutes. There was a very sharp increase in running time for the non-consolidated version after around 1 million total shuffle files. Below this threshold, however, there wasn't a significant difference between the two.

Better performance measurement of this patch is warranted, and I plan on doing so in the near future as part of a general investigation of our shuffle file bottlenecks and performance.

(cherry picked from commit 48952d67e6dde25faaba241b9deba737b83a5372)
Signed-off-by: Reynold Xin <rxin@apache.org>
Merge pull request #92 from tgravescs/sparkYarnFixClasspath

Fix the Worker to use CoarseGrainedExecutorBackend and modify classpath ...

...to be explicit about inclusion of spark.jar and app.jar.  Be explicit so if there are any conflicts in packaging between spark.jar and app.jar we don't get random results due to the classpath having /*, which can including things in different order.

(cherry picked from commit b84193c5b86d60f36624ae29169cf62e489005af)
Signed-off-by: Reynold Xin <rxin@apache.org>
Merge pull request #90 from pwendell/master

SPARK-940: Do not directly pass Stage objects to SparkListener.

This patch updates the SparkListener interface to pass StageInfo objects rather than directly pass spark Stages. The reason for this patch is explained in detail in SPARK-940.
(cherry picked from commit c404adb9d2238644415fd93270871f5a8a9ce455)

Signed-off-by: Patrick Wendell <pwendell@gmail.com>
Merge pull request #100 from JoshRosen/spark-902

Remove redundant Java Function call() definitions

This should fix [SPARK-902](https://spark-project.atlassian.net/browse/SPARK-902), an issue where some Java API Function classes could cause AbstractMethodErrors when user code is compiled using the Eclipse compiler.

Thanks to @MartinWeindel for diagnosing this problem.

(This PR subsumes #30).

(cherry picked from commit 9dfcf53a08645227b8722f07068466c7b7909721)
Signed-off-by: Reynold Xin <rxin@apache.org>
Merge branch 'branch-0.8' of https://git-wip-us.apache.org/repos/asf/incubator-spark into branch-0.8
Merge pull request #103 from JoshRosen/unpersist-fix

Add unpersist() to JavaDoubleRDD and JavaPairRDD.

This fixes a minor inconsistency where [unpersist() was only available on JavaRDD](https://mail-archives.apache.org/mod_mbox/incubator-spark-user/201310.mbox/%3CCE8D8748.68C0%25YannLuppo%40livenation.com%3E) and not JavaPairRDD / JavaDoubleRDD.   I also added support for the new optional `blocking` argument added in 0.8.

Please merge this into branch-0.8, too.

(cherry picked from commit a098438c4824891fb44e9119e038e6e796c69741)
Signed-off-by: Reynold Xin <rxin@apache.org>