-
Notifications
You must be signed in to change notification settings - Fork 14.5k
KAFKA-19073: add transactional ID pattern filter to ListTransactions #19355
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
KAFKA-19073: add transactional ID pattern filter to ListTransactions #19355
Conversation
A label of 'needs-attention' was automatically added to this PR in order to raise the |
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.
@CalvinConfluent thanks for this patch!
core/src/main/scala/kafka/coordinator/transaction/TransactionStateManager.scala
Outdated
Show resolved
Hide resolved
clients/src/main/resources/common/message/ListTransactionsRequest.json
Outdated
Show resolved
Hide resolved
core/src/main/scala/kafka/coordinator/transaction/TransactionStateManager.scala
Outdated
Show resolved
Hide resolved
clients/src/main/java/org/apache/kafka/clients/admin/ListTransactionsOptions.java
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.
Thanks @CalvinConfluent for this patch, a little comments
clients/src/test/java/org/apache/kafka/clients/admin/internals/ListTransactionsHandlerTest.java
Outdated
Show resolved
Hide resolved
clients/src/test/java/org/apache/kafka/clients/admin/internals/ListTransactionsHandlerTest.java
Outdated
Show resolved
Hide resolved
tools/src/test/java/org/apache/kafka/tools/TransactionsCommandTest.java
Outdated
Show resolved
Hide resolved
tools/src/test/java/org/apache/kafka/tools/TransactionsCommandTest.java
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.
@CalvinConfluent thanks for this patch. one small comment is left. PTAL
@@ -75,6 +75,9 @@ public ListTransactionsRequest.Builder buildBatchedRequest( | |||
.map(TransactionState::toString) | |||
.collect(Collectors.toList())); | |||
request.setDurationFilter(options.filteredDuration()); | |||
if (!options.filteredTransactionalIdPattern().isEmpty()) { |
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.
filteredTransactionalIdPattern
is nullable, so should we add null check?
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 filteredTransactionalIdPattern in the ListTransactionsOptions, the default value is "" and we only update it if the user sets the --transactional-id-pattern
. It should be valid.
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.
or could you please add null check to ListTransactionsOptions#filterOnTransactionalIdPattern
if we don't want to user to set it to null.
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.
Sounds good, updated.
clients/src/main/java/org/apache/kafka/common/requests/ListTransactionsRequest.java
Outdated
Show resolved
Hide resolved
@@ -30,6 +32,9 @@ | |||
}, | |||
{ "name": "DurationFilter", "type": "int64", "versions": "1+", "default": -1, | |||
"about": "Duration (in millis) to filter by: if < 0, all transactions will be returned; otherwise, only transactions running longer than this duration will be returned." | |||
}, | |||
{ "name": "TransactionalIdPattern", "type": "string", "versions": "2+", "nullableVersions": "2+", "default": "null", |
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.
I'm a little confused by why we convert null to "" on the client side if we allow null and it's the same result as "" (but we do the extra step of filtering for "" on the server side)
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.
Yeah, I think it is because the other regex fields allow null. So we want to get they aligned, like SubscribedTopicRegex
in ConsumerGroupHeartbeatRequest. As for converting to an empty string, I find it is convenient to handle in code.
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.
Any reason why we can't just accept null on the client side? We convert to "" now.
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.
I have updated the client side not to convert null in ListTransactionsOptions#filterOnTransactionalIdPattern
. Also adding necessary null handlings.
@@ -2472,7 +2472,17 @@ class KafkaApis(val requestChannel: RequestChannel, | |||
val filteredProducerIds = listTransactionsRequest.data.producerIdFilters.asScala.map(Long.unbox).toSet | |||
val filteredStates = listTransactionsRequest.data.stateFilters.asScala.toSet | |||
val durationFilter = listTransactionsRequest.data.durationFilter() | |||
val response = txnCoordinator.handleListTransactions(filteredProducerIds, filteredStates, durationFilter) | |||
val transactionalIdPatternFilter = if (listTransactionsRequest.data.transactionalIdPattern == null) { | |||
"" |
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.
Do we need this as well? We have a null check in TransactionStateManager
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.
val pattern = if (filterTransactionalIdPattern.nonEmpty) {
try {
Pattern.compile(filterTransactionalIdPattern)
}
catch {
case e: PatternSyntaxException =>
throw new InvalidRegularExpression(String.format("Transaction ID pattern `%s` is not a valid regular expression: %s.", filterTransactionalIdPattern, e.getMessage))
}
} else null
It seems TransactionStateManager
does not check the null for filterTransactionalIdPattern
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.
I see. I was looking at the lines directly above where we do check for null. It's a bit confusing which things check for null vs empty 😓
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.
The main reason to convert null to an empty string is to avoid null handling in the downstream. But yeah, looks like there is only one place to check null. Updated to use null in the code path.
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.
Thanks Calvin!
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!
@chia7712 Any other comments? Thanks! |
…pache#19355) Propose adding a new filter TransactionalIdPattern. This transaction ID pattern filter works as AND with the other transaction filters. Also, it is empowered with Re2j. KIP: https://cwiki.apache.org/confluence/x/4gm9F Reviewers: Justine Olshan <[email protected]>, Ken Huang <[email protected]>, Kuan-Po Tseng <[email protected]>, Chia-Ping Tsai <[email protected]>
https://issues.apache.org/jira/browse/KAFKA-19073
Reviewers: Justine Olshan [email protected], Ken Huang
[email protected], Kuan-Po Tseng [email protected], Chia-Ping
Tsai [email protected]