-
Notifications
You must be signed in to change notification settings - Fork 14k
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-5366: Add concurrent reads to transactions system test #3217
KAFKA-5366: Add concurrent reads to transactions system test #3217
Conversation
71fcad1
to
051e77a
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
051e77a
to
f6f15cb
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
f6f15cb
to
52028b8
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
… exercise the abort index
…esn't close prematurely when there are broker bounces
36603a1
to
07b378f
Compare
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 for the patch. Left a couple trivial comments.
@@ -242,6 +242,9 @@ public synchronized boolean ensurePartitionAdded(TopicPartition tp) { | |||
// We should enter this branch in an error state because if this partition is already in the transaction, | |||
// there is a chance that the corresponding batch is in retry. So we must let it completely flush. | |||
if (!(partitionsInTransaction.contains(tp) || isPartitionPending(tp))) { | |||
log.debug("partitionsInTransaction: [{}], newPartitionsInTransaction: [{}], " + |
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.
Is this intentional or were you just using this for your own debugging? If it's intentional, we should probably add the log prefix and make the message a little clearer.
# ensure that the consumer is up. | ||
wait_until(lambda: (len(consumer.messages_consumed[1]) > 0) == True, | ||
timeout_sec=60, | ||
err_msg="Consumer failed to consume any messages for for %ds" %\ |
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.
nit: extra "for"
return consumer | ||
|
||
def drain_consumer(self, consumer): | ||
# wait until the consumer closes, which will be 15 seconds after |
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.
This comment doesn't seem to match what the wait_until
is doing.
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
These are starting to stabilize:
|
Kicked off a branch builder for this single test. Not sure if jenkins is ready though: http://jenkins.confluent.io/job/system-test-kafka-branch-builder/902/ |
Refer to this link for build results (access rights to CI server 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.
LGTM. The coordinator disconnect handling is a good find.
Refer to this link for build results (access rights to CI server needed): |
Second successful run: http://jenkins.confluent.io/job/system-test-kafka-branch-builder-2/301/ |
Refer to this link for build results (access rights to CI server needed): |
Third successful run: http://jenkins.confluent.io/job/system-test-kafka-branch-builder-2/302 |
Merging to trunk and 0.11.0. |
This currently fails in multiple ways. One of which is most likely KAFKA-5355, where the concurrent consumer reads duplicates. During broker bounces, the concurrent consumer misses messages completely. This is another bug. Author: Apurva Mehta <apurva@confluent.io> Reviewers: Jason Gustafson <jason@confluent.io> Closes #3217 from apurvam/KAFKA-5366-add-concurrent-reads-to-transactions-system-test (cherry picked from commit 202cb8e) Signed-off-by: Jason Gustafson <jason@confluent.io>
This currently fails in multiple ways. One of which is most likely KAFKA-5355, where the concurrent consumer reads duplicates.
During broker bounces, the concurrent consumer misses messages completely. This is another bug.