fix: fix issues with multi-statement requests failing to validate #3952
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fixes: confluentinc#3363 Issue was that the `prepare` call is throwing if the meta-store doesn't contain the sources in a statement. Given a request contains a later statement that depends on an earlier statement, e.g. ```sql CREATE STREAM FOO (...) WITH (...); CREATE STREAM BAR AS SELECT * ``` The KSQL correctly validates the statements, because it updates the sandboxed copy of the meta-store as it goes. However, when it comes to executing the statement it once against `prepares` the statement. Only this time its using the true meta-store and that is only updated by the command runner thread. This can mean that the first statement is correctly written to the command topic, but if the next statement is `prepare`'d before the command runner thread executes the statement and updates the meta-store, then the `prepare` call on the rest-request thead will fail with an error that `FOO` does not exist. The server has the ability to wait for a previous command to be executed by the command runner thread before executing the next. However, this isn't done for _distributed_ statements, i.e. those written to the command topic as its not meant to be required. It is done for statements such as `SHOW STREAMS`, which need to have any previous command executed as it may be creating a stream! This is fixed in master already. The fix was to _not_ have `prepare` validate that the source exists. This is the correct fix. However, this would be a big change for 5.4.x. Instead, this commit makes two changes: 1. Move the check to wait for previous commands to _before_ the `prepare` call. 2. All statement types should wait for previous commands to finish. (Because we check _before_ `prepare` we don't _know_ the statement type). This fixes the race condition at the cost of more synchronisation. However, this synchronisation will only impact multi-statement requests. The CLI generally issues single line requests, so no impact. C3 issues multi-line requests, i.e. the entire script in one go. So this will slow down responses to C3 slightly, but will stop intermittent fails in C3 if there are interdependent statements.
vcrfxia
approved these changes
Nov 22, 2019
agavra
approved these changes
Nov 22, 2019
big-andy-coates
changed the title
big-andy-coates
changed the title
big-andy-coates
added a commit
that referenced
this pull request
Nov 23, 2019
Deliberately not merging the fixes for #3952 into master, as this issue is already resolved in master
|
Merged into 5.3.x |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
fixes: #3363
Issue was that the
preparecall is throwing if the meta-store doesn't contain the sources in a statement.Given a request contains a later statement that depends on an earlier statement, e.g.
The KSQL correctly validates the statements, because it updates the sandboxed copy of the meta-store as it goes.
However, when it comes to executing the statement it once against
preparesthe statement. Only this time its using the true meta-store and that is only updated by the command runner thread. This can mean that the first statement is correctly written to the command topic, but if the next statement isprepare'd before the command runner thread executes the statement and updates the meta-store, then thepreparecall on the rest-request thead will fail with an error thatFOOdoes not exist.The server has the ability to wait for a previous command to be executed by the command runner thread before executing the next. However, this isn't done for distributed statements, i.e. those written to the command topic as its not meant to be required. It is done for statements such as
SHOW STREAMS, which need to have any previous command executed as it may be creating a stream!This is fixed in master already. The fix was to not have
preparevalidate that the source exists. This is the correct fix. However, this would be a big change for 5.4.x. Instead, this commit makes two changes:preparecall.preparewe don't know the statement type).This fixes the race condition at the cost of more synchronisation. However, this synchronisation will only impact multi-statement requests. The CLI generally issues single line requests, so no impact. C3 issues multi-line requests, i.e. the entire script in one go. So this will slow down responses to C3 slightly, but will stop intermittent fails in C3 if there are interdependent statements.
Pros:
run scriptwork.Cons:
Testing done
usual + manual.
Reviewer checklist