[
https://issues.apache.org/jira/browse/KAFKA-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095721#comment-16095721
]
james chien edited comment on KAFKA-5606 at 7/21/17 3:35 AM:
-------------------------------------------------------------
So the goal is returning type of enum instead of boolean, specifically is
following statement:
{code:java}
RequestFuture.succeeded()
{code} with an enum of SUCCEEDED,
{code:java}
RequestFuture.failed()
{code} with an enum of FAILED,
and
{code:java}
RequestFuture.isRetriable()
{code} with an enum of RETRY
was (Author: james.c):
So the goal is replacing
{code:java}
RequestFuture.succeeded()
{code} with enum of SUCCEEDED,
{code:java}
RequestFuture.failed()
{code} with enum of FAILED,
and
{code:java}
RequestFuture.isRetriable()
{code} with enum of RETRY ?
> 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: 0.11.1.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)
