Skip to content
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

fix: Always dec. concurrency counter, even hitting rate limits #8165

Merged
merged 4 commits into from
Sep 24, 2021

Conversation

AlanConfluent
Copy link
Member

Description

When the bandwidth rate limit is hit, it never decrements the concurrency counter. This change ensures it always does.

Testing done

Ran tests and verified manually

Reviewer checklist

  • Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
  • Ensure relevant issues are linked (description should include text like "Fixes #")

Copy link
Member

@cprasad1 cprasad1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM @AlanConfluent. Thanks for the fix! Couple of minor comments

@@ -316,7 +316,7 @@ private EndpointResponse handleStatement(
}
} catch (final TopicAuthorizationException e) {
return errorHandler.accessDeniedFromKafkaResponse(e);
} catch (final KsqlStatementException e) {
} catch (final KsqlStatementException e) {;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mistakenly added ;?

@@ -93,6 +96,7 @@ protected synchronized void allow(final KsqlQueryType ksqlQueryType, final long
this.numBytesInWindow -= responseSizesLog.poll().right;
}
if (this.numBytesInWindow > throttleLimit) {
LOG.warn("Hit bandwidth rate limit of " + throttleLimit + " with use of " + numBytesInWindow);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add the unit MB in the warning message here to be more explicit

@cprasad1
Copy link
Member

@AlanConfluent Do we foresee the concurrency counter not getting decremented when we hit other types of exceptions in pull query execution?

Copy link
Member

@vvcephei vvcephei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @AlanConfluent ! This is a great catch.

I just had one question.

} catch (final Throwable t) {
LOG.error("Error closing pull query queue", t);
}
future.complete(null);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It shouldn't be completed exceptionally if we fail to close?

@AlanConfluent AlanConfluent merged commit 0e05519 into confluentinc:master Sep 24, 2021
cprasad1 pushed a commit that referenced this pull request Oct 4, 2021
* fix: Always dec. concurrency counter, even hitting rate limits
cprasad1 pushed a commit to cprasad1/ksql that referenced this pull request Oct 4, 2021
…uentinc#8165)

* fix: Always dec. concurrency counter, even hitting rate limits
wcarlson5 pushed a commit that referenced this pull request Oct 5, 2021
#8223)

* fix: Always dec. concurrency counter, even hitting rate limits (#8165)

* fix: Always dec. concurrency counter, even hitting rate limits

* chore: fix pull query compilation

Co-authored-by: Alan Sheinberg <[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