date:20150202

[jira] [Updated] (SPARK-5180) Data source API improvement

2015-02-02 Thread Michael Armbrust (JIRA)


 [ 
https://issues.apache.org/jira/browse/SPARK-5180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Armbrust updated SPARK-5180:

Target Version/s: 1.4.0  (was: 1.3.0)

 Data source API improvement
 ---

 Key: SPARK-5180
 URL: https://issues.apache.org/jira/browse/SPARK-5180
 Project: Spark
  Issue Type: Improvement
  Components: SQL
Reporter: Yin Huai
Priority: Blocker





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Updated] (SPARK-4768) Add Support For Impala Encoded Timestamp (INT96)

2015-02-02 Thread Michael Armbrust (JIRA)


 [ 
https://issues.apache.org/jira/browse/SPARK-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Armbrust updated SPARK-4768:

Priority: Blocker  (was: Critical)

 Add Support For Impala Encoded Timestamp (INT96)
 

 Key: SPARK-4768
 URL: https://issues.apache.org/jira/browse/SPARK-4768
 Project: Spark
  Issue Type: Improvement
  Components: SQL
Reporter: Pat McDonough
Priority: Blocker
 Attachments: 5e4481a02f951e29-651ee94ed14560bf_922627129_data.0.parq, 
 string_timestamp.gz


 Impala is using INT96 for timestamps. Spark SQL should be able to read this 
 data despite the fact that it is not part of the spec.
 Perhaps adding a flag to act like impala when reading parquet (like we do for 
 strings already) would be useful.
 Here's an example of the error you might see:
 {code}
 Caused by: java.lang.RuntimeException: Potential loss of precision: cannot 
 convert INT96
 at scala.sys.package$.error(package.scala:27)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$.toPrimitiveDataType(ParquetTypes.scala:61)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$.toDataType(ParquetTypes.scala:113)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$$anonfun$convertToAttributes$1.apply(ParquetTypes.scala:314)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$$anonfun$convertToAttributes$1.apply(ParquetTypes.scala:311)
 at 
 scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:244)
 at 
 scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:244)
 at scala.collection.Iterator$class.foreach(Iterator.scala:727)
 at scala.collection.AbstractIterator.foreach(Iterator.scala:1157)
 at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
 at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
 at 
 scala.collection.TraversableLike$class.map(TraversableLike.scala:244)
 at scala.collection.AbstractTraversable.map(Traversable.scala:105)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$.convertToAttributes(ParquetTypes.scala:310)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$.readSchemaFromFile(ParquetTypes.scala:441)
 at 
 org.apache.spark.sql.parquet.ParquetRelation.init(ParquetRelation.scala:66)
 at org.apache.spark.sql.SQLContext.parquetFile(SQLContext.scala:141)
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Updated] (SPARK-4768) Add Support For Impala Encoded Timestamp (INT96)

2015-02-02 Thread Michael Armbrust (JIRA)


 [ 
https://issues.apache.org/jira/browse/SPARK-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Armbrust updated SPARK-4768:

Assignee: Yin Huai

 Add Support For Impala Encoded Timestamp (INT96)
 

 Key: SPARK-4768
 URL: https://issues.apache.org/jira/browse/SPARK-4768
 Project: Spark
  Issue Type: Improvement
  Components: SQL
Reporter: Pat McDonough
Assignee: Yin Huai
Priority: Blocker
 Attachments: 5e4481a02f951e29-651ee94ed14560bf_922627129_data.0.parq, 
 string_timestamp.gz


 Impala is using INT96 for timestamps. Spark SQL should be able to read this 
 data despite the fact that it is not part of the spec.
 Perhaps adding a flag to act like impala when reading parquet (like we do for 
 strings already) would be useful.
 Here's an example of the error you might see:
 {code}
 Caused by: java.lang.RuntimeException: Potential loss of precision: cannot 
 convert INT96
 at scala.sys.package$.error(package.scala:27)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$.toPrimitiveDataType(ParquetTypes.scala:61)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$.toDataType(ParquetTypes.scala:113)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$$anonfun$convertToAttributes$1.apply(ParquetTypes.scala:314)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$$anonfun$convertToAttributes$1.apply(ParquetTypes.scala:311)
 at 
 scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:244)
 at 
 scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:244)
 at scala.collection.Iterator$class.foreach(Iterator.scala:727)
 at scala.collection.AbstractIterator.foreach(Iterator.scala:1157)
 at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
 at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
 at 
 scala.collection.TraversableLike$class.map(TraversableLike.scala:244)
 at scala.collection.AbstractTraversable.map(Traversable.scala:105)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$.convertToAttributes(ParquetTypes.scala:310)
 at 
 org.apache.spark.sql.parquet.ParquetTypesConverter$.readSchemaFromFile(ParquetTypes.scala:441)
 at 
 org.apache.spark.sql.parquet.ParquetRelation.init(ParquetRelation.scala:66)
 at org.apache.spark.sql.SQLContext.parquetFile(SQLContext.scala:141)
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Updated] (SPARK-3851) Support for reading parquet files with different but compatible schema

2015-02-02 Thread Michael Armbrust (JIRA)


 [ 
https://issues.apache.org/jira/browse/SPARK-3851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Armbrust updated SPARK-3851:

Priority: Blocker  (was: Critical)

 Support for reading parquet files with different but compatible schema
 --

 Key: SPARK-3851
 URL: https://issues.apache.org/jira/browse/SPARK-3851
 Project: Spark
  Issue Type: Improvement
  Components: SQL
Reporter: Michael Armbrust
Assignee: Cheng Lian
Priority: Blocker

 Right now it is required that all of the parquet files have the same schema.  
 It would be nice to support some safe subset of cases where the schemas of 
 files is different.  For example:
  - Adding and removing nullable columns.
  - Widening types (a column that is of both Int and Long type)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Updated] (SPARK-5425) ConcurrentModificationException during SparkConf creation

2015-02-02 Thread Josh Rosen (JIRA)


 [ 
https://issues.apache.org/jira/browse/SPARK-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Rosen updated SPARK-5425:
--
Target Version/s: 1.2.2

I've merged [~jlewandowski]'s patch (https://github.com/apache/spark/pull/4222) 
to fix this in `master` (1.3.0) and `branch-1.1` (1.1.2), and I've added the 
{{backport-needed}} tag so we remember to merge it into 1.2.2.

 ConcurrentModificationException during SparkConf creation
 -

 Key: SPARK-5425
 URL: https://issues.apache.org/jira/browse/SPARK-5425
 Project: Spark
  Issue Type: Bug
  Components: Spark Core
Affects Versions: 1.1.1, 1.2.0
Reporter: Jacek Lewandowski
Assignee: Jacek Lewandowski
 Fix For: 1.3.0, 1.1.2


 This fragment of code:
 {code}
   if (loadDefaults) {
 // Load any spark.* system properties
 for ((k, v) - System.getProperties.asScala if k.startsWith(spark.)) {
   settings(k) = v
 }
   }
 {code}
 causes 
 {noformat}
 ERROR 09:43:15  SparkMaster service caused error in state 
 STARTINGjava.util.ConcurrentModificationException: null
   at java.util.Hashtable$Enumerator.next(Hashtable.java:1167) 
 ~[na:1.7.0_60]
   at 
 scala.collection.convert.Wrappers$JPropertiesWrapper$$anon$3.next(Wrappers.scala:458)
  ~[scala-library-2.10.4.jar:na]
   at 
 scala.collection.convert.Wrappers$JPropertiesWrapper$$anon$3.next(Wrappers.scala:454)
  ~[scala-library-2.10.4.jar:na]
   at scala.collection.Iterator$class.foreach(Iterator.scala:727) 
 ~[scala-library-2.10.4.jar:na]
   at scala.collection.AbstractIterator.foreach(Iterator.scala:1157) 
 ~[scala-library-2.10.4.jar:na]
   at scala.collection.IterableLike$class.foreach(IterableLike.scala:72) 
 ~[scala-library-2.10.4.jar:na]
   at scala.collection.AbstractIterable.foreach(Iterable.scala:54) 
 ~[scala-library-2.10.4.jar:na]
   at 
 scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:771)
  ~[scala-library-2.10.4.jar:na]
   at org.apache.spark.SparkConf.init(SparkConf.scala:53) 
 ~[spark-core_2.10-1.2.1_dse-20150121.075638-2.jar:1.2.1_dse-SNAPSHOT]
   at org.apache.spark.SparkConf.init(SparkConf.scala:47) 
 ~[spark-core_2.10-1.2.1_dse-20150121.075638-2.jar:1.2.1_dse-SNAPSHOT]
 {noformat}
 when there is another thread which modifies system properties at the same 
 time. 
 This bug https://issues.scala-lang.org/browse/SI-7775 is somehow related to 
 the issue and shows that the problem has been also found elsewhere. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Commented] (SPARK-5534) EdgeRDD, VertexRDD getStorageLevel return bad values

2015-02-02 Thread Joseph K. Bradley (JIRA)


[ 
https://issues.apache.org/jira/browse/SPARK-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302043#comment-14302043
 ] 

Joseph K. Bradley commented on SPARK-5534:
--

Note: This is needed for [https://github.com/apache/spark/pull/4047], which is 
a PR for this JIRA: [https://issues.apache.org/jira/browse/SPARK-1405]

 EdgeRDD, VertexRDD getStorageLevel return bad values
 

 Key: SPARK-5534
 URL: https://issues.apache.org/jira/browse/SPARK-5534
 Project: Spark
  Issue Type: Bug
  Components: GraphX
Affects Versions: 1.3.0
Reporter: Joseph K. Bradley

 After caching a graph, its edge and vertex RDDs still return 
 StorageLevel.None.
 Reproduce error:
 {code}
 import org.apache.spark.graphx.{Edge, Graph}
 val edges = Seq(
   Edge[Double](0, 1, 0),
   Edge[Double](1, 2, 0),
   Edge[Double](2, 3, 0),
   Edge[Double](3, 4, 0))
 val g = Graph.fromEdges[Double,Double](sc.parallelize(edges), 0)
 g.vertices.getStorageLevel  // returns value for StorageLevel.None
 g.edges.getStorageLevel  // returns value for StorageLevel.None
 g.cache()
 g.vertices.count()
 g.edges.count()
 g.vertices.getStorageLevel  // returns value for StorageLevel.None
 g.edges.getStorageLevel  // returns value for StorageLevel.None
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Assigned] (SPARK-5534) EdgeRDD, VertexRDD getStorageLevel return bad values

2015-02-02 Thread Joseph K. Bradley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SPARK-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph K. Bradley reassigned SPARK-5534:


Assignee: Joseph K. Bradley

 EdgeRDD, VertexRDD getStorageLevel return bad values
 

 Key: SPARK-5534
 URL: https://issues.apache.org/jira/browse/SPARK-5534
 Project: Spark
  Issue Type: Bug
  Components: GraphX
Affects Versions: 1.3.0
Reporter: Joseph K. Bradley
Assignee: Joseph K. Bradley

 After caching a graph, its edge and vertex RDDs still return 
 StorageLevel.None.
 Reproduce error:
 {code}
 import org.apache.spark.graphx.{Edge, Graph}
 val edges = Seq(
   Edge[Double](0, 1, 0),
   Edge[Double](1, 2, 0),
   Edge[Double](2, 3, 0),
   Edge[Double](3, 4, 0))
 val g = Graph.fromEdges[Double,Double](sc.parallelize(edges), 0)
 g.vertices.getStorageLevel  // returns value for StorageLevel.None
 g.edges.getStorageLevel  // returns value for StorageLevel.None
 g.cache()
 g.vertices.count()
 g.edges.count()
 g.vertices.getStorageLevel  // returns value for StorageLevel.None
 g.edges.getStorageLevel  // returns value for StorageLevel.None
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Commented] (SPARK-5505) ConsumerRebalanceFailedException from Kafka consumer

2015-02-02 Thread Tathagata Das (JIRA)


[ 
https://issues.apache.org/jira/browse/SPARK-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302062#comment-14302062
 ] 

Tathagata Das commented on SPARK-5505:
--

Since this is a problem with the HighLevel consumer, solving this requires 
completely rearchitecting the KafkaReceiver. This is hard to do. Possible 
workarounds:
http://mail-archives.apache.org/mod_mbox/kafka-users/201312.mbox/%3CCAFbh0Q38qQ0aAg_cj=jzk-kbi8xwf+1m6xlj+fzf6eetj9z...@mail.gmail.com%3E

 ConsumerRebalanceFailedException from Kafka consumer
 

 Key: SPARK-5505
 URL: https://issues.apache.org/jira/browse/SPARK-5505
 Project: Spark
  Issue Type: Bug
  Components: Streaming
Affects Versions: 1.2.0
 Environment: CentOS6 / Linux 2.6.32-358.2.1.el6.x86_64
 java version 1.7.0_21
 Scala compiler version 2.9.3
 2 cores Intel(R) Xeon(R) CPU E5620  @ 2.40GHz / 16G RAM
 VMWare VM.
Reporter: Greg Temchenko
Priority: Critical

 From time to time Spark streaming produces a ConsumerRebalanceFailedException 
 and stops receiving messages. After that all consequential RDDs are empty.
 {code}
 15/01/30 18:18:36 ERROR consumer.ZookeeperConsumerConnector: 
 [terran_vmname-1422670149779-243b4e10], error during syncedRebalance
 kafka.common.ConsumerRebalanceFailedException: 
 terran_vmname-1422670149779-243b4e10 can't rebalance after 4 retries
   at 
 kafka.consumer.ZookeeperConsumerConnector$ZKRebalancerListener.syncedRebalance(ZookeeperConsumerConnector.scala:432)
   at 
 kafka.consumer.ZookeeperConsumerConnector$ZKRebalancerListener$$anon$1.run(ZookeeperConsumerConnector.scala:355)
 {code}
 The problem is also described in the mailing list: 
 http://apache-spark-user-list.1001560.n3.nabble.com/Error-when-Spark-streaming-consumes-from-Kafka-td19570.html
 As I understand it's a critical blocker for kafka-spark streaming production 
 use.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Updated] (SPARK-5514) collect should call executeCollect

2015-02-02 Thread Michael Armbrust (JIRA)


 [ 
https://issues.apache.org/jira/browse/SPARK-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Armbrust updated SPARK-5514:

Assignee: Reynold Xin

 collect should call executeCollect
 --

 Key: SPARK-5514
 URL: https://issues.apache.org/jira/browse/SPARK-5514
 Project: Spark
  Issue Type: Sub-task
  Components: SQL
Affects Versions: 1.3.0
Reporter: Reynold Xin
Assignee: Reynold Xin
Priority: Blocker





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Resolved] (SPARK-5491) Chi-square feature selection

2015-02-02 Thread Xiangrui Meng (JIRA)


 [ 
https://issues.apache.org/jira/browse/SPARK-5491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xiangrui Meng resolved SPARK-5491.
--
   Resolution: Fixed
Fix Version/s: 1.3.0

Issue resolved by pull request 1484
[https://github.com/apache/spark/pull/1484]

 Chi-square feature selection
 

 Key: SPARK-5491
 URL: https://issues.apache.org/jira/browse/SPARK-5491
 Project: Spark
  Issue Type: New Feature
  Components: MLlib
Reporter: Xiangrui Meng
Assignee: Alexander Ulanov
 Fix For: 1.3.0


 Implement chi-square feature selection. PR: 
 https://github.com/apache/spark/pull/1484



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Closed] (SPARK-5437) DriverSuite and SparkSubmitSuite incorrect timeout behavior

2015-02-02 Thread Andrew Or (JIRA)


 [ 
https://issues.apache.org/jira/browse/SPARK-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Or closed SPARK-5437.

  Resolution: Fixed
   Fix Version/s: 1.3.0
Target Version/s: 1.3.0

 DriverSuite and SparkSubmitSuite incorrect timeout behavior
 ---

 Key: SPARK-5437
 URL: https://issues.apache.org/jira/browse/SPARK-5437
 Project: Spark
  Issue Type: Bug
  Components: Spark Core
Affects Versions: 1.0.0
Reporter: Andrew Or
Assignee: Andrew Or
 Fix For: 1.3.0


 In DriverSuite, we currently set a timeout of 60 seconds. If after this time 
 the process has not terminated, we leak the process because we never destroy 
 it.
 In SparkSubmitSuite, we currently do not have a timeout so the test can hang 
 indefinitely.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Updated] (SPARK-5388) Provide a stable application submission gateway in standalone cluster mode

2015-02-02 Thread Andrew Or (JIRA)


 [ 
https://issues.apache.org/jira/browse/SPARK-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Or updated SPARK-5388:
-
Summary: Provide a stable application submission gateway in standalone 
cluster mode  (was: Provide a stable application submission gateway)

 Provide a stable application submission gateway in standalone cluster mode
 --

 Key: SPARK-5388
 URL: https://issues.apache.org/jira/browse/SPARK-5388
 Project: Spark
  Issue Type: Bug
  Components: Spark Core
Affects Versions: 1.2.0
Reporter: Andrew Or
Assignee: Andrew Or
Priority: Blocker
 Attachments: Stable Spark Standalone Submission.pdf


 The existing submission gateway in standalone mode is not compatible across 
 Spark versions. If you have a newer version of Spark submitting to an older 
 version of the standalone Master, it is currently not guaranteed to work. The 
 goal is to provide a stable REST interface to replace this channel.
 The first cut implementation will target standalone cluster mode because 
 there are very few messages exchanged. The design, however, will be general 
 enough to eventually support this for other cluster managers too. Note that 
 this is not necessarily required in YARN because we already use YARN's stable 
 interface to submit applications there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Updated] (SPARK-5388) Provide a stable application submission gateway in standalone cluster mode

2015-02-02 Thread Andrew Or (JIRA)

[
https://issues.apache.org/jira/browse/SPARK-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrew Or updated SPARK-5388:
-
Description:
The existing submission gateway in standalone mode is not compatible across
Spark versions. If you have a newer version of Spark submitting to an older
version of the standalone Master, it is currently not guaranteed to work. The
goal is to provide a stable REST interface to replace this channel.

The first cut implementation will target standalone cluster mode because there
are very few messages exchanged. The design, however, should be general enough
to potentially support this for other cluster managers too. Note that this is
not necessarily required in YARN because we already use YARN's stable interface
to submit applications there.

was:
The existing submission gateway in standalone mode is not compatible across
Spark versions. If you have a newer version of Spark submitting to an older
version of the standalone Master, it is currently not guaranteed to work. The
goal is to provide a stable REST interface to replace this channel.

The first cut implementation will target standalone cluster mode because there
are very few messages exchanged. The design, however, will be general enough to
eventually support this for other cluster managers too. Note that this is not
necessarily required in YARN because we already use YARN's stable interface to
submit applications there.

Provide a stable application submission gateway in standalone cluster mode
--

Key: SPARK-5388
URL: https://issues.apache.org/jira/browse/SPARK-5388
Project: Spark
Issue Type: Bug
Components: Spark Core
Affects Versions: 1.2.0
Reporter: Andrew Or
Assignee: Andrew Or
Priority: Blocker
Attachments: Stable Spark Standalone Submission.pdf

The existing submission gateway in standalone mode is not compatible across
Spark versions. If you have a newer version of Spark submitting to an older
version of the standalone Master, it is currently not guaranteed to work. The
goal is to provide a stable REST interface to replace this channel.
The first cut implementation will target standalone cluster mode because
there are very few messages exchanged. The design, however, should be general
enough to potentially support this for other cluster managers too. Note that
this is not necessarily required in YARN because we already use YARN's stable
interface to submit applications there.

1 2 >

1 - 100 of 196 matches

Mail list logo