-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-17919] Make timeout to RBackend configurable in SparkR #15471
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
Changes from all commits
9dde457
d27233c
ae655bc
84bf8df
630467e
26e9179
3744623
6f15a15
fcc3376
749c8b0
666b609
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -18,16 +18,19 @@ | |
| package org.apache.spark.api.r | ||
|
|
||
| import java.io.{ByteArrayInputStream, ByteArrayOutputStream, DataInputStream, DataOutputStream} | ||
| import java.util.concurrent.TimeUnit | ||
|
|
||
| import scala.collection.mutable.HashMap | ||
| import scala.language.existentials | ||
|
|
||
| import io.netty.channel.{ChannelHandlerContext, SimpleChannelInboundHandler} | ||
| import io.netty.channel.ChannelHandler.Sharable | ||
| import io.netty.handler.timeout.ReadTimeoutException | ||
|
|
||
| import org.apache.spark.api.r.SerDe._ | ||
| import org.apache.spark.internal.Logging | ||
| import org.apache.spark.util.Utils | ||
| import org.apache.spark.SparkConf | ||
| import org.apache.spark.util.{ThreadUtils, Utils} | ||
|
|
||
| /** | ||
| * Handler for RBackend | ||
|
|
@@ -83,7 +86,29 @@ private[r] class RBackendHandler(server: RBackend) | |
| writeString(dos, s"Error: unknown method $methodName") | ||
| } | ||
| } else { | ||
| // To avoid timeouts when reading results in SparkR driver, we will be regularly sending | ||
| // heartbeat responses. We use special code +1 to signal the client that backend is | ||
| // alive and it should continue blocking for result. | ||
| val execService = ThreadUtils.newDaemonSingleThreadScheduledExecutor("SparkRKeepAliveThread") | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure how expensive it is to create and destroy an executor service each time. Can we just schedule at fixed rate when we get the request and then cancel the schedule at the end of the request ?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was not sure about this either. I used this method based on advice from @zsxwing.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm - my question on whether we can reuse this still stands. @zsxwing do you think thats possible ?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @shivaram we can reuse it.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I took a closer look at this and (a) it looks like the executor just calls cancel on the tasks during shutdown, so that part of the behavior is the same as calling cancel on the task we have [1]. But you are right that if we wanted to wait for termination we'd need to do some extra work. We could use the But overall it looks like thread pool creation is only around 100 micro-seconds [2] and I also benchmarked this locally. [1] http://www.docjar.com/html/api/java/util/concurrent/ScheduledThreadPoolExecutor.java.html line 367 |
||
| val pingRunner = new Runnable { | ||
| override def run(): Unit = { | ||
| val pingBaos = new ByteArrayOutputStream() | ||
| val pingDaos = new DataOutputStream(pingBaos) | ||
| writeInt(pingDaos, +1) | ||
| ctx.write(pingBaos.toByteArray) | ||
| } | ||
| } | ||
| val conf = new SparkConf() | ||
| val heartBeatInterval = conf.getInt( | ||
| "spark.r.heartBeatInterval", SparkRDefaults.DEFAULT_HEARTBEAT_INTERVAL) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should this be documented too?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done. |
||
| val backendConnectionTimeout = conf.getInt( | ||
| "spark.r.backendConnectionTimeout", SparkRDefaults.DEFAULT_CONNECTION_TIMEOUT) | ||
| val interval = Math.min(heartBeatInterval, backendConnectionTimeout - 1) | ||
|
|
||
| execService.scheduleAtFixedRate(pingRunner, interval, interval, TimeUnit.SECONDS) | ||
| handleMethodCall(isStatic, objId, methodName, numArgs, dis, dos) | ||
| execService.shutdown() | ||
| execService.awaitTermination(1, TimeUnit.SECONDS) | ||
| } | ||
|
|
||
| val reply = bos.toByteArray | ||
|
|
@@ -95,9 +120,15 @@ private[r] class RBackendHandler(server: RBackend) | |
| } | ||
|
|
||
| override def exceptionCaught(ctx: ChannelHandlerContext, cause: Throwable): Unit = { | ||
| // Close the connection when an exception is raised. | ||
| cause.printStackTrace() | ||
| ctx.close() | ||
| cause match { | ||
| case timeout: ReadTimeoutException => | ||
| // Do nothing. We don't want to timeout on read | ||
| logWarning("Ignoring read timeout in RBackendHandler") | ||
| case _ => | ||
| // Close the connection when an exception is raised. | ||
| cause.printStackTrace() | ||
| ctx.close() | ||
| } | ||
| } | ||
|
|
||
| def handleMethodCall( | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,30 @@ | ||
| /* | ||
| * Licensed to the Apache Software Foundation (ASF) under one or more | ||
| * contributor license agreements. See the NOTICE file distributed with | ||
| * this work for additional information regarding copyright ownership. | ||
| * The ASF licenses this file to You under the Apache License, Version 2.0 | ||
| * (the "License"); you may not use this file except in compliance with | ||
| * the License. You may obtain a copy of the License at | ||
| * | ||
| * http://www.apache.org/licenses/LICENSE-2.0 | ||
| * | ||
| * Unless required by applicable law or agreed to in writing, software | ||
| * distributed under the License is distributed on an "AS IS" BASIS, | ||
| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| * See the License for the specific language governing permissions and | ||
| * limitations under the License. | ||
| */ | ||
|
|
||
| package org.apache.spark.api.r | ||
|
|
||
| private[spark] object SparkRDefaults { | ||
|
|
||
| // Default value for spark.r.backendConnectionTimeout config | ||
| val DEFAULT_CONNECTION_TIMEOUT: Int = 6000 | ||
|
|
||
| // Default value for spark.r.heartBeatInterval config | ||
| val DEFAULT_HEARTBEAT_INTERVAL: Int = 100 | ||
|
|
||
| // Default value for spark.r.numRBackendThreads config | ||
| val DEFAULT_NUM_RBACKEND_THREADS = 2 | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure SparkConf has been initialized successfully at this point ? Or to to put it another way, in which cases does this code path get called from ? Is this in the
spark-submitcase or the shell etc. ?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is for
spark-submit. Basically the JVM starts before the R process. As a result the only way for R process to get these configuration parameters from the JVM. In this case,RBackendsets the environment variables based on configs.For the other mode where JVM is started after the R process, we are sending this timeout value through the TCP connection.
At least that is my current understanding of how deploy modes work. In our production environment we launch the R process from the JVM.