KAFKA-7140: Remove deprecated poll usages - #5319
Conversation
|
Thanks for the PR. Maybe we can update all non-test usages of the deprecated method at once? |
|
@ijuma thanks for the suggestion, I've updated the PR. |
There was a problem hiding this comment.
@mjsax I think you authored the change where this line was introduced. Do you know what's the reasoning for poll(1)? Did it just used the fact that it updated the metadata or were there any other reasons? I'm not sure that my change is correct here and I don't have the context.
There was a problem hiding this comment.
Yes, we do this call to update the metadata. The change seems reasonable to me.
There was a problem hiding this comment.
Are you sure about this? poll(1) would previously have guaranteed that the consumer joins the group. That is no longer the case with the new poll, so the call to assignment below is likely to return an empty set.
There was a problem hiding this comment.
Because StreamsResetter must be the only member in the group (we check on startup that the group is empty), we can check if the assignment contains all offsets? Or we could switch to manual assignment?
There was a problem hiding this comment.
Yeah, I think manual assignment is a better option here. For one thing, it guarantees that there won't be another member in the group when you receive the assignment. It also gets around the awkward use of poll() since you do not actually want to fetch data. The basic approach would be to use the partitionsFor API to find the partitions for the subscribed topics and then assign them directly with assign.
There was a problem hiding this comment.
Ok, I'll try to refactor my code this way.
|
Also created a jira for this as it I think it now exceeds the "minor" category :) |
|
@viktorsomogyi Thanks for the patch. Note that there is a semantic difference between the old and new |
|
retest this please |
|
@hachikuji thanks for the note. Yes, I've been trying to keep in mind that poll(0) differs in this case. In some cases we could just use to the position call or poll(0) just because we make sure to have an initial value to an iterator, etc. |
hachikuji
left a comment
There was a problem hiding this comment.
Apologies for the delay. Left a couple comments.
There was a problem hiding this comment.
Maybe we can just initialize this to an empty iterator? The call seems intended to join the group, but that will no longer happen when the call returns.
There was a problem hiding this comment.
Were you thinking about something like this?
var recordIter = Collections.emptyList[ConsumerRecord[Array[Byte], Array[Byte]]]().iterator()
There was a problem hiding this comment.
As far as I can tell, the assignment will be empty here. I don't think the old code worked either as intended because it did the seekToEnd prior to the call to poll(). For an end-to-end latency test, I actually wonder if we should just use manual assignment and take the group management out of the picture?
There was a problem hiding this comment.
Will change to manual assignment, something like this (which seems to work).
val topicPartitions = consumer.listTopics().get(topic).asScala
.map(pi => new TopicPartition(pi.topic(), pi.partition()))
.to[List].asJava
consumer.assign(topicPartitions)
consumer.seekToEnd(topicPartitions)
consumer.assignment().asScala.foreach(consumer.position)
c53957e to
6ae1afa
Compare
There was a problem hiding this comment.
So here it seems the old code assumed that there is a topic. Now I added a check that there must be a topic beforehand. the producer would anyway create it according to the default settings but I think that most of the latency tests executed by users won't depend on the default settings and they rather want to create topics manually according to their likings.
There was a problem hiding this comment.
I guess another approach might be to produce a dummy record to the topic first before assigning the partitions to the consumer and starting the test. That would let us retain the existing behavior.
bcf8279 to
6ad6f5e
Compare
| try (final KafkaConsumer<byte[], byte[]> client = new KafkaConsumer<>(config, new ByteArrayDeserializer(), new ByteArrayDeserializer())) { | ||
| client.subscribe(topicsToSubscribe); | ||
| client.poll(1); | ||
| Map<String, List<PartitionInfo>> pi = client.listTopics(); |
There was a problem hiding this comment.
Not final yet, will refactor it a bit as suggested in earlier comments.
| try (final KafkaConsumer<byte[], byte[]> client = new KafkaConsumer<>(config, new ByteArrayDeserializer(), new ByteArrayDeserializer())) { | ||
| client.subscribe(topicsToSubscribe); | ||
| client.poll(1); | ||
| Collection<TopicPartition> partitions = topicsToSubscribe.stream().map(client::partitionsFor) |
There was a problem hiding this comment.
@hachikuji were you thinking of something like this?
There was a problem hiding this comment.
Java 8 makes this much nicer than I was expecting. 😄
|
General update:
|
|
retest this please |
|
@viktorsomogyi There is a checkstyle error |
hachikuji
left a comment
There was a problem hiding this comment.
Thanks for the updates. Just one comment for discussion.
| try (final KafkaConsumer<byte[], byte[]> client = new KafkaConsumer<>(config, new ByteArrayDeserializer(), new ByteArrayDeserializer())) { | ||
| client.subscribe(topicsToSubscribe); | ||
| client.poll(1); | ||
| Collection<TopicPartition> partitions = topicsToSubscribe.stream().map(client::partitionsFor) |
There was a problem hiding this comment.
Java 8 makes this much nicer than I was expecting. 😄
There was a problem hiding this comment.
I guess another approach might be to produce a dummy record to the topic first before assigning the partitions to the consumer and starting the test. That would let us retain the existing behavior.
|
@viktorsomogyi Thanks for the update. LGTM overall. I think to fix the failing tests, we just need to use the right |
|
Ah, indeed. If you haven't started fixing it yet, I pushed a commit with that. Let's see if we'll have any after this. :) |
|
It seems there was a flaky afterall. I'll rerun them. |
|
retest this please |
|
Can this be dropped from Consumer (in trunk) ? |
|
@tedyu We cannot just remove a method from public API, as this would be a breaking change. Note, that the method is already |
EndToEndLatency tool produces a dummy record in case the topic does not exist. This behavior was introduced in this PR #5319 as part of updating the tool to use latest consumer API. However, if we run the tool with producer acks == 1, the high watermark may not be updated before we reset consumer offsets to latest. In rare cases when this happens, the tool will throw an exception in the for loop where the consumer will unexpectedly consume the dummy record. As a result, we occasionally see Benchmark.test_end_to_end_latency system test failures. This PR checks if topic exists, and creates the topic using AdminClient if it does not exist. Author: Anna Povzner <anna@confluent.io> Reviewers: Ismael Juma <ismael@juma.me.uk>, Ewen Cheslack-Postava <ewen@confluent.io> Closes #5950 from apovzner/fix-EndToEndLatency (cherry picked from commit 3acebe6) Signed-off-by: Ewen Cheslack-Postava <me@ewencp.org>
EndToEndLatency tool produces a dummy record in case the topic does not exist. This behavior was introduced in this PR #5319 as part of updating the tool to use latest consumer API. However, if we run the tool with producer acks == 1, the high watermark may not be updated before we reset consumer offsets to latest. In rare cases when this happens, the tool will throw an exception in the for loop where the consumer will unexpectedly consume the dummy record. As a result, we occasionally see Benchmark.test_end_to_end_latency system test failures. This PR checks if topic exists, and creates the topic using AdminClient if it does not exist. Author: Anna Povzner <anna@confluent.io> Reviewers: Ismael Juma <ismael@juma.me.uk>, Ewen Cheslack-Postava <ewen@confluent.io> Closes #5950 from apovzner/fix-EndToEndLatency
EndToEndLatency tool produces a dummy record in case the topic does not exist. This behavior was introduced in this PR apache#5319 as part of updating the tool to use latest consumer API. However, if we run the tool with producer acks == 1, the high watermark may not be updated before we reset consumer offsets to latest. In rare cases when this happens, the tool will throw an exception in the for loop where the consumer will unexpectedly consume the dummy record. As a result, we occasionally see Benchmark.test_end_to_end_latency system test failures. This PR checks if topic exists, and creates the topic using AdminClient if it does not exist. Author: Anna Povzner <anna@confluent.io> Reviewers: Ismael Juma <ismael@juma.me.uk>, Ewen Cheslack-Postava <ewen@confluent.io> Closes apache#5950 from apovzner/fix-EndToEndLatency (cherry picked from commit 3acebe6) Signed-off-by: Ewen Cheslack-Postava <me@ewencp.org>
Reviewers: Matthias J. Sax <mjsax@apache.org>, Jason Gustafson <jason@confluent.io>
EndToEndLatency tool produces a dummy record in case the topic does not exist. This behavior was introduced in this PR apache#5319 as part of updating the tool to use latest consumer API. However, if we run the tool with producer acks == 1, the high watermark may not be updated before we reset consumer offsets to latest. In rare cases when this happens, the tool will throw an exception in the for loop where the consumer will unexpectedly consume the dummy record. As a result, we occasionally see Benchmark.test_end_to_end_latency system test failures. This PR checks if topic exists, and creates the topic using AdminClient if it does not exist. Author: Anna Povzner <anna@confluent.io> Reviewers: Ismael Juma <ismael@juma.me.uk>, Ewen Cheslack-Postava <ewen@confluent.io> Closes apache#5950 from apovzner/fix-EndToEndLatency
Committer Checklist (excluded from commit message)