kafka-jira mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "james chien (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (KAFKA-5606) Review consumer's RequestFuture usage pattern
Date Fri, 21 Jul 2017 03:36:01 GMT

    [ 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)

Mime
View raw message