Skip to content

[SPARK-21991][LAUNCHER] Fix race condition in LauncherServer#acceptConnections #19217

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

[SPARK-21991][LAUNCHER] Fix race condition in LauncherServer#acceptConnections #19217

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 13 additions & 13 deletions launcher/src/main/java/org/apache/spark/launcher/LauncherServer.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -232,20 +232,20 @@ public void run() {
};
ServerConnection clientConnection = new ServerConnection(client, timeout);
Thread clientThread = factory.newThread(clientConnection);
synchronized (timeout) {
Copy link
Contributor

@ash211 ash211 Oct 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we're no longer synchronizing on the timeout here, but I didn't see anywhere else synchronizing on it either (including ServerConnection). Given it doesn't escape this method, I'm not sure how multiple threads could ever access timeout at once, so it makes sense to remove this synchronization

Copy link
Author

@nivox nivox Oct 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was exactly my reasoning. I couldn't find any reason why the synchronisation was needed. The removal was only a means to make the code simpler removing the cognitive cost suggested by the presence of a synchronise keyword. The actual fix doesn't depend on it.

clientThread.start();
synchronized (clients) {
clients.add(clientConnection);
}
long timeoutMs = getConnectionTimeout();
// 0 is used for testing to avoid issues with clock resolution / thread scheduling,
// and force an immediate timeout.
if (timeoutMs > 0) {
timeoutTimer.schedule(timeout, getConnectionTimeout());
} else {
timeout.run();
}
synchronized (clients) {
clients.add(clientConnection);
Copy link
Contributor

@ash211 ash211 Oct 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we are now adding to clients before starting the clientThread instead of after. What's the expected ordering for these two operations?

Copy link
Author

@nivox nivox Oct 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding the connection to clients before starting the thread should be safer since otherwise the thread could have a chance of running and terminating before the connection is added to clients. This would cause the addition of an already terminated connection to the clients list which nobody would ever cleanup (i.e. memory leak).

This situation is really unlikely but still a possibility.

Changing the order of operation shouldn't affect any logic since the clients list is only used for cleanup in the close method.

}

long timeoutMs = getConnectionTimeout();
// 0 is used for testing to avoid issues with clock resolution / thread scheduling,
// and force an immediate timeout.
if (timeoutMs > 0) {
timeoutTimer.schedule(timeout, timeoutMs);
Copy link
Contributor

@ash211 ash211 Oct 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on not calling getConnectionTimeout() multiple times

} else {
timeout.run();
}

clientThread.start();
}
} catch (IOException ioe) {
if (running) {
Expand Down