[
https://issues.apache.org/jira/browse/KAFKA-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16156372#comment-16156372
]
ASF GitHub Bot commented on KAFKA-5606:
---------------------------------------
Github user jedichien closed the pull request at:
https://github.com/apache/kafka/pull/3667
> Review consumer's RequestFuture usage pattern
> ---------------------------------------------
>
> Key: KAFKA-5606
> URL: https://issues.apache.org/jira/browse/KAFKA-5606
> Project: Kafka
> Issue Type: Bug
> Reporter: Ismael Juma
> Assignee: james chien
> Fix For: 1.0.0
>
>
> KAFKA-5556 shows that we can perhaps tighten the usage pattern of the
> consumer's RequestFuture to avoid similar bugs in the future.
> Jason suggested:
> {quote}
> Another way to see this bug is a failure to ensure completion of the future.
> Had we done so, then we could have skipped the failed check. This is why it
> worked prior to the patch which added the timeout. The pattern should really
> be something like this:
> {code}
> if (future.isDone()) {
> if (future.succeeded()) {
> // handle success
> } else {
> // handle failure
> }
> }
> {code}
> I guess one benefit of the enum approach is that it forces you to ensure
> completion prior to checking any of the possible results. That said, I'm a
> bit more inclined to remove the isRetriable method and leave it to the caller
> to determine what is and is not retriable. Then the request future only has
> two completion states.
> {quote}
> An alternative is replacing succeeded and failed with a status method
> returning an enum with 3 states: SUCCEEDED, FAILED, RETRY (the enum approach
> mentioned above). This would make sense if we often have to handle these 3
> states differently.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
