Github user squito commented on a diff in the pull request:
https://github.com/apache/spark/pull/6205#discussion_r31828271
--- Diff: core/src/main/scala/org/apache/spark/rpc/RpcEnv.scala ---
@@ -182,3 +185,130 @@ private[spark] object RpcAddress {
RpcAddress(host, port)
}
}
+
+
+/**
+ * An exception thrown if RpcTimeout modifies a [[TimeoutException]].
+ */
+private[rpc] class RpcTimeoutException(message: String)
+ extends TimeoutException(message)
+
+
+/**
+ * Associates a timeout with a description so that a when a
TimeoutException occurs, additional
+ * context about the timeout can be amended to the exception message.
+ * @param timeout timeout duration in seconds
+ * @param description description to be displayed in a timeout exception
+ */
+private[spark] class RpcTimeout(timeout: FiniteDuration, description:
String) {
+
+ /** Get the timeout duration */
+ def duration: FiniteDuration = timeout
+
+ /** Get the message associated with this timeout */
+ def message: String = description
+
+ /** Amends the standard message of TimeoutException to include the
description */
+ def createRpcTimeoutException(te: TimeoutException): RpcTimeoutException
= {
+ new RpcTimeoutException(te.getMessage() + " " + description)
+ }
+
+ /**
+ * Add a callback to the given Future so that if it completes as failed
with a TimeoutException
+ * then the timeout description is added to the message
+ */
+ def addMessageIfTimeout[T](future: Future[T]): Future[T] = {
+ future.recover {
+ // Add a warning message if Future is passed to
addMessageIfTimeoutTest more than once
+ case rte: RpcTimeoutException => throw new
RpcTimeoutException(rte.getMessage() +
+ " (Future has multiple calls to
RpcTimeout.addMessageIfTimeoutTest)")
+ // Any other TimeoutException get converted to a RpcTimeoutException
with modified message
--- End diff --
we could do the same trick with the exceptions, to avoid appending the
message multiple times to the message. You could return a new subclass of
`Future`, which just delegates all methods to whatever it wrapped, and this
method would be a no-op if called on that subclass.
But IMO, this is just not worth the complication ... honestly I am already
slightly regretting taking us down this path, the benefit is pretty marginal.
At least I've learned something along the way, I hope you feel the same :)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
