[
https://issues.apache.org/jira/browse/KAFKA-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253083#comment-15253083
]
ASF GitHub Bot commented on KAFKA-3602:
---------------------------------------
GitHub user hachikuji opened a pull request:
https://github.com/apache/kafka/pull/1254
KAFKA-3602: rename RecordAccumulator dequeFor() and fix usage
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/hachikuji/kafka KAFKA-3602
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/kafka/pull/1254.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1254
----
----
> Rename RecordAccumulator dequeFor() and ensure proper usage
> -----------------------------------------------------------
>
> Key: KAFKA-3602
> URL: https://issues.apache.org/jira/browse/KAFKA-3602
> Project: Kafka
> Issue Type: Bug
> Reporter: Jason Gustafson
> Assignee: Jason Gustafson
>
> In the investigation of KAFKA-3358, we found a case where the side effect of
> creating record batches in the internal RecordAccumulator.dequeFor()
> method caused unintended behavior. The bug in this case an implicit
> assumption elsewhere in the code that all record batches correspond to
> partitions that have actually been targeted for sends by the user. This
> assumption was invalidated when a topic metadata request is sent with no
> topics, which results in the metadata from all topics being returned. The end
> result when that happened is that the client gets stuck trying to fetch
> metadata for topics which were not even used.
> Although this particular problem will be fixed by changing the TopicMetadata
> request in KIP-4, it probably could have been avoided by making the
> side-effect of batch creation clear in the method name. For example, instead
> of dequeFor(), we should use something like getOrCreateDeque(). It's more
> verbose, but it makes the behavior clear. From a scan of the code, it looks
> like there are a couple places where we do not expect the side-effect of
> batch creation, so we should fix that too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
