Skip to content

Conversation

@srowen
Copy link
Member

@srowen srowen commented Jun 29, 2016

What changes were proposed in this pull request?

Utils.terminateProcess should destroy() first and only fall back to destroyForcibly() if it fails. It's kind of bad that we're force-killing executors -- and only in Java 8. See JIRA for an example of the impact: no shutdown

While here: Utils.waitForProcess should use the Java 8 method if available instead of a custom implementation.

How was this patch tested?

Existing tests, which cover the force-kill case, and Amplab tests, which will cover both Java 7 and Java 8 eventually. However I tested locally on Java 8 and the PR builder will try Java 7 here.

…estroyForcibly() if it fails. Utils.waitForProcess should use Java 8 method if available.
@SparkQA
Copy link

SparkQA commented Jun 29, 2016

Test build #61469 has finished for PR 13973 at commit 50ee5b6.

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

asfgit pushed a commit that referenced this pull request Jul 1, 2016
…cess.destroyForcibly() if and only if Process.destroy() fails

## What changes were proposed in this pull request?

Utils.terminateProcess should `destroy()` first and only fall back to `destroyForcibly()` if it fails. It's kind of bad that we're force-killing executors -- and only in Java 8. See JIRA for an example of the impact: no shutdown

While here: `Utils.waitForProcess` should use the Java 8 method if available instead of a custom implementation.

## How was this patch tested?

Existing tests, which cover the force-kill case, and Amplab tests, which will cover both Java 7 and Java 8 eventually. However I tested locally on Java 8 and the PR builder will try Java 7 here.

Author: Sean Owen <[email protected]>

Closes #13973 from srowen/SPARK-16182.

(cherry picked from commit 2075bf8)
Signed-off-by: Sean Owen <[email protected]>
@srowen
Copy link
Member Author

srowen commented Jul 1, 2016

Merged to master/2.0/1.6. I went ahead with this as I think it's a reasonably important fix for something that only manifests in Java 8, that we hard-kill executors and don't let them for example finish shutdown hook cleanup at all.

@asfgit asfgit closed this in 2075bf8 Jul 1, 2016
asfgit pushed a commit that referenced this pull request Jul 1, 2016
…cess.destroyForcibly() if and only if Process.destroy() fails

## What changes were proposed in this pull request?

Utils.terminateProcess should `destroy()` first and only fall back to `destroyForcibly()` if it fails. It's kind of bad that we're force-killing executors -- and only in Java 8. See JIRA for an example of the impact: no shutdown

While here: `Utils.waitForProcess` should use the Java 8 method if available instead of a custom implementation.

## How was this patch tested?

Existing tests, which cover the force-kill case, and Amplab tests, which will cover both Java 7 and Java 8 eventually. However I tested locally on Java 8 and the PR builder will try Java 7 here.

Author: Sean Owen <[email protected]>

Closes #13973 from srowen/SPARK-16182.

(cherry picked from commit 2075bf8)
Signed-off-by: Sean Owen <[email protected]>
@srowen srowen deleted the SPARK-16182 branch July 1, 2016 08:25
zzcclp pushed a commit to zzcclp/spark that referenced this pull request Jul 1, 2016
…cess.destroyForcibly() if and only if Process.destroy() fails

## What changes were proposed in this pull request?

Utils.terminateProcess should `destroy()` first and only fall back to `destroyForcibly()` if it fails. It's kind of bad that we're force-killing executors -- and only in Java 8. See JIRA for an example of the impact: no shutdown

While here: `Utils.waitForProcess` should use the Java 8 method if available instead of a custom implementation.

## How was this patch tested?

Existing tests, which cover the force-kill case, and Amplab tests, which will cover both Java 7 and Java 8 eventually. However I tested locally on Java 8 and the PR builder will try Java 7 here.

Author: Sean Owen <[email protected]>

Closes apache#13973 from srowen/SPARK-16182.

(cherry picked from commit 2075bf8)
Signed-off-by: Sean Owen <[email protected]>
(cherry picked from commit 83f8604)
@yhuai
Copy link
Contributor

yhuai commented Jul 11, 2016

@srowen
Copy link
Member Author

srowen commented Jul 11, 2016

Oh, I think @vanzin fixed that and it wasn't then back-ported to 1.6: #14056 I can do that.

dongjoon-hyun pushed a commit that referenced this pull request Apr 18, 2024
### What changes were proposed in this pull request?
The pr aims to upgrade `netty` from `4.1.108.Final` to `4.1.109.Final`.

### Why are the changes needed?
https://netty.io/news/2024/04/15/4-1-109-Final.html
This version has brought some bug fixes and improvements, such as:
- Fix DefaultChannelId#asLongText NPE ([#13971](netty/netty#13971))
- Rewrite ZstdDecoder to remove the need of allocate a huge byte[] internally ([#13928](netty/netty#13928))
- Don't send a RST frame when closing the stream in a write future while processing inbound frames ([#13973](netty/netty#13973))

### Does this PR introduce _any_ user-facing change?
No.

### How was this patch tested?
Pass GA.

### Was this patch authored or co-authored using generative AI tooling?
No.

Closes #46112 from panbingkun/netty_for_spark4.

Authored-by: panbingkun <[email protected]>
Signed-off-by: Dongjoon Hyun <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants