aboutsummaryrefslogtreecommitdiff
path: root/docs/configuration.md
diff options
context:
space:
mode:
authorJosh Rosen <joshrosen@databricks.com>2016-11-01 16:23:47 -0700
committerReynold Xin <rxin@databricks.com>2016-11-01 16:23:47 -0700
commit6e6298154aba63831a292117797798131a646869 (patch)
tree83851dd672c106050ad78f521e0b22807ad1b15c /docs/configuration.md
parent01dd0083011741c2bbe5ae1d2a25f2c9a1302b76 (diff)
downloadspark-6e6298154aba63831a292117797798131a646869.tar.gz
spark-6e6298154aba63831a292117797798131a646869.tar.bz2
spark-6e6298154aba63831a292117797798131a646869.zip
[SPARK-17350][SQL] Disable default use of KryoSerializer in Thrift Server
In SPARK-4761 / #3621 (December 2014) we enabled Kryo serialization by default in the Spark Thrift Server. However, I don't think that the original rationale for doing this still holds now that most Spark SQL serialization is now performed via encoders and our UnsafeRow format. In addition, the use of Kryo as the default serializer can introduce performance problems because the creation of new KryoSerializer instances is expensive and we haven't performed instance-reuse optimizations in several code paths (including DirectTaskResult deserialization). Given all of this, I propose to revert back to using JavaSerializer as the default serializer in the Thrift Server. /cc liancheng Author: Josh Rosen <joshrosen@databricks.com> Closes #14906 from JoshRosen/disable-kryo-in-thriftserver.
Diffstat (limited to 'docs/configuration.md')
-rw-r--r--docs/configuration.md5
1 files changed, 2 insertions, 3 deletions
diff --git a/docs/configuration.md b/docs/configuration.md
index 780fc94908..0017219e07 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -767,7 +767,7 @@ Apart from these, the following properties are also available, and may be useful
</tr>
<tr>
<td><code>spark.kryo.referenceTracking</code></td>
- <td>true (false when using Spark SQL Thrift Server)</td>
+ <td>true</td>
<td>
Whether to track references to the same object when serializing data with Kryo, which is
necessary if your object graphs have loops and useful for efficiency if they contain multiple
@@ -838,8 +838,7 @@ Apart from these, the following properties are also available, and may be useful
<tr>
<td><code>spark.serializer</code></td>
<td>
- org.apache.spark.serializer.<br />JavaSerializer (org.apache.spark.serializer.<br />
- KryoSerializer when using Spark SQL Thrift Server)
+ org.apache.spark.serializer.<br />JavaSerializer
</td>
<td>
Class to use for serializing objects that will be sent over the network or need to be cached