Github user JoshRosen commented on a diff in the pull request:
https://github.com/apache/spark/pull/1632#discussion_r16091512
--- Diff:
core/src/main/scala/org/apache/spark/network/ConnectionManager.scala ---
@@ -836,9 +845,14 @@ private[spark] class ConnectionManager(
def sendMessageReliably(connectionManagerId: ConnectionManagerId,
message: Message)
: Future[Message] = {
val promise = Promise[Message]()
+
+ val ackTimeoutMonitor = new Timer(s"Ack Timeout Monitor-" +
+ "${connectionManagerId}-MessageId(${message.id})", true)
+
val status = new MessageStatus(message, connectionManagerId, s => {
+ ackTimeoutMonitor.cancel()
--- End diff --
Even though access to `isAckTimeout` is guarded by the `messageStatuses`
lock, I think there's still a race condition here. According to the
[Timer.cancel()](http://docs.oracle.com/javase/7/docs/api/java/util/Timer.html#cancel())
docs, `cancel()` "does not interfere with a currently executing task (if it
exists)." So, there's still the potential for the timeout task to race with
the message, start running and get blocked waiting to synchronize, and
eventually run and throw an exception.
---
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]
