-
Notifications
You must be signed in to change notification settings - Fork 62
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
Adds Compile-Time Thread.interrupted()
checks
#398
Conversation
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.
LGTM, some minor questions below.
lang/src/org/partiql/lang/eval/visitors/VisitorTransformBase.kt
Outdated
Show resolved
Hide resolved
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.
LGTM overall. Only have a couple nits/suggestions. Also, should these checks also be added to the v0.1.5 tag @dlurton ?
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.
Some minor nits.
Can you also add an interrupt
check in the function validateTopLevelNodes
in SqlParser
?
Since it recurses over the entire tree, I remember it had very "high flames" in the CPU profiler.
c12f36d
to
41d2e15
Compare
-- Added a check to |
That's next after this has been merged to |
41d2e15
to
3bc9116
Compare
Codecov Report
@@ Coverage Diff @@
## master #398 +/- ##
============================================
+ Coverage 81.88% 81.91% +0.02%
- Complexity 1350 1351 +1
============================================
Files 168 169 +1
Lines 10491 10508 +17
Branches 1737 1738 +1
============================================
+ Hits 8591 8608 +17
Misses 1360 1360
Partials 540 540
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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.
LGTM. Thanks.
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.
For the future, I recommend that you try to avoid rebasing/squashing commits after you get feedback as it makes it impossible for the reviewer to do inter-diffs or only look at what you changed.
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.
Noticed one small typo. Rest of changes LGTM
* to [transformExpr]. | ||
* | ||
* All transforms should derive from this class instead of [PartiqlAst.VisitorTransform] so that they can | ||
* be interrupted of they take a long time to process large ASTs. |
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.
typo: "be interrupted if..."
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.
Fixed
8c8b5e5
Yes, sorry, I realized that too late. |
* Add Thread.interrupted() checks
A few times over the past few years we've received reports from a PartiQL service where with a customer sending a very large query (in terms of size of the SQL), where PartiQL would take a long time (>30s) to parse, rewrite, validate, and compile.
Although we have optimized every case where this has happened, this PR applies a mitigation measure which can be used in case it happens again. I have identified several "hot" loops where the state of
Thread.interrupted()
can be polled and if set anInterruptedException
is thrown. This is the hope that if such a query is encountered again, it can be aborted by the calling code rather than risk causing service outages. This approach still might miss loops that we did not anticipate would become hot in the case of unexpected user input, but at least this should allow most such scenarios to be aborted. If it later discovered that we missed such a hot loop in the future, it is a simple matter to add a call tocheckThreadInterrupted()
.What this PR does not do is add an evaluation-time poll for
Thread.interrupted()
. That will come in another PR if it is later determined to be needed.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.