[SPARK-11655] [core] Fix deadlock in handling of launcher stop().

[vanzin]

The stop() callback was trying to close the launcher connection in the
same thread that handles connection data, which ended up causing a
deadlock. So avoid that by dispatching the stop() request in its own
thread.

On top of that, add some exception safety to a few parts of the code,
and use "destroyForcibly" from Java 8 if it's available, to force
kill the child process. The flip side is that "kill()" may not actually
work if running Java 7.

[vanzin]

@JoshRosen

[SparkQA]

Test build #45656 has finished for PR 9633 at commit 9fcd201.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[JoshRosen]

I can confirm that this seems to fix the problem when running locally.

[JoshRosen]

Based on http://bugs.java.com/view_bug.do?bug_id=4073195, it sounds like many *nix implementations of Process.destroy() work by sending SIGTERM to the child process. I suppose that anything that caused SIGTERM to be swallowed / ignored by one of the child processes could keep this from working on Java 7. PySpark used to be vulnerable to similar problems, so it includes a test case which specifically checks the SIGTERM-handling behavior:

spark/python/pyspark/tests.py

Line 1580 in b8ff688

"""Ensure that daemon and workers terminate on SIGTERM."""

I commented out the handle.stop() call and verified that the child process stops almost immediately under Java 7, so it appears that this has fixed the issue. I suppose that we could try adding regression tests, but I'd also be fine doing that as a followup; I'd like to try to get this fix in sooner rather than later given the impact that it will have on Jenkins performance.

[JoshRosen]

I was initially worried that this needs to be in a try block but it doesn't look like disconnect() is capable of throwing any exceptions.

[vanzin]

Note that the fix is NOT about whether destroy or destroyForcibly is used. The fix was a real deadlock in the code; that was made worse by the destroy call not actually killing the child process, which caused the process leak.

With the deadlock out of the way, calling destroy shouldn't really be needed since the child process will exit properly.

[vanzin]

@JoshRosen do you have any extra feedback here? I'll push the change otherwise.

[vanzin]

Merging to master / 1.6, we can do post-review later if needed.

[JoshRosen]

Sorry for the late / flaky review replies; I've been home sick with strep throat and spent most of the day asleep. This seems fine to me.

[JoshRosen]

Maybe I'm overlooking something really obvious, but I think it's pretty hard to spot the circular wait condition which led to the deadlock. For posterity, could you post a brief description of the participants in that cycle?

[vanzin]

LauncherBackend.close() waits for the communication thread to finish execution, so it can't be called from that thread or it will deadlock. (It's a little weird that you're even allowed to do that, but go figure.)