-
Notifications
You must be signed in to change notification settings - Fork 28.1k
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.
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
[SPARK-7862][SQL]Fix the deadlock in script transformation for stderr #6404
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -17,6 +17,10 @@ | |
|
||
package org.apache.spark.sql.hive.execution | ||
|
||
import org.scalatest.concurrent.Timeouts._ | ||
import org.scalatest.time.Span | ||
import org.scalatest.time.Millis | ||
|
||
import org.apache.spark.sql.catalyst.DefaultParserDialect | ||
import org.apache.spark.sql.catalyst.analysis.EliminateSubQueries | ||
import org.apache.spark.sql.catalyst.errors.DialectException | ||
|
@@ -629,12 +633,24 @@ class SQLQuerySuite extends QueryTest { | |
.queryExecution.analyzed | ||
} | ||
|
||
test("test script transform") { | ||
test("test script transform for stdout") { | ||
val data = (1 to 100000).map { i => (i, i, i) } | ||
data.toDF("d1", "d2", "d3").registerTempTable("script_trans") | ||
assert(100000 === | ||
sql("SELECT TRANSFORM (d1, d2, d3) USING 'cat' AS (a,b,c) FROM script_trans") | ||
.queryExecution.toRdd.count()) | ||
failAfter(Span(20000, Millis)) { | ||
assert(100000 === | ||
sql("SELECT TRANSFORM (d1, d2, d3) USING 'cat' AS (a,b,c) FROM script_trans") | ||
.queryExecution.toRdd.count()) | ||
} | ||
} | ||
|
||
test("test script transform for stderr") { | ||
val data = (1 to 100000).map { i => (i, i, i) } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This test will flush the stderr while testing, should we generate less data or hide it someway? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agree. Filed SPARK-8508 and PR #6925 to shrink unnecessary output. |
||
data.toDF("d1", "d2", "d3").registerTempTable("script_trans") | ||
failAfter(Span(20000, Millis)) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 20s is probably long enough that we won't have a problem, but do we really need this? I'm worried if a jenkins machine is overloaded we might have false failures. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Put it here just to ensure if the deadlock happen again it can be somehow detected. (although in theory it would not be an option any more). Any advice ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes, I think 20000 ms is reasonable, in most of cases, we will not run the code for such long time, so it's not a problem for Jenkins testing. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It will be detected, the build will hang and get aborted. In theory any query could deadlock, so why do we need this extra logic for only this test case? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, without the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And what happens if a unit test hangs... the build fails. Any unit test in theory could hang, why is this the only one that we are now making timing dependent? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It doesn't mean we will stop here for 20 seconds. And we don't want to keep the deadlock noticed in 2 hours then jenkins testing timeout, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, I got you mean, we thought that would be explicitly to reminder the developer for this specific timeout / failure. |
||
assert(0 === | ||
sql("SELECT TRANSFORM (d1, d2, d3) USING 'cat 1>&2' AS (a,b,c) FROM script_trans") | ||
.queryExecution.toRdd.count()) | ||
} | ||
} | ||
|
||
test("window function: udaf with aggregate expressin") { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a comment explaining why this is needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
builder.redirectError(Redirect.INHERIT)
would consuming the error output from buffer and then print it to stderr (inherit the target from the current Scala process).If without this there would be 2 issues:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Put the comment in the source code.