[jira] [Commented] (KAFKA-7042) Fall back to the old behavior when the broker is too old to recognize LIST_OFFSET versions

2018-06-11 Thread Ismael Juma (JIRA)


[ 
https://issues.apache.org/jira/browse/KAFKA-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508845#comment-16508845
 ] 

Ismael Juma commented on KAFKA-7042:


Maybe they should not turn it on for older brokers?

> Fall back to the old behavior when the broker is too old to recognize 
> LIST_OFFSET versions
> --
>
> Key: KAFKA-7042
> URL: https://issues.apache.org/jira/browse/KAFKA-7042
> Project: Kafka
>  Issue Type: Improvement
>  Components: consumer
>Reporter: Guozhang Wang
>Priority: Major
>
> When READ_COMMITTED is turned on (since 0.11.0), LIST_OFFSET requires 
> min_version to be 2 on the consumer client side. On the other hand, if broker 
> is no newer than 0.10.2 it can only recognize the version of LIST_OFFSET up 
> to 1. In this case the consumer talking to such an old broker will throw an 
> exception right away.
> What we can improve though, is that when the consumer realized broker does 
> not recognize LIST_OFFSET of at least 2, it can fall back to the old behavior 
> of READ_UNCOMMITTED since the data on that broker should not have any txn 
> markers anyways. By doing this we would lift the hard restriction that 
> consumers with READ_COMMITTED cannot work with an older version of broker 
> (remember we are trying to achieve broker compatibility since 0.10.0).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (KAFKA-7042) Fall back to the old behavior when the broker is too old to recognize LIST_OFFSET versions

2018-06-11 Thread Guozhang Wang (JIRA)


[ 
https://issues.apache.org/jira/browse/KAFKA-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508815#comment-16508815
 ] 

Guozhang Wang commented on KAFKA-7042:
--

System tests.

> Fall back to the old behavior when the broker is too old to recognize 
> LIST_OFFSET versions
> --
>
> Key: KAFKA-7042
> URL: https://issues.apache.org/jira/browse/KAFKA-7042
> Project: Kafka
>  Issue Type: Improvement
>  Components: consumer
>Reporter: Guozhang Wang
>Priority: Major
>
> When READ_COMMITTED is turned on (since 0.11.0), LIST_OFFSET requires 
> min_version to be 2 on the consumer client side. On the other hand, if broker 
> is no newer than 0.10.2 it can only recognize the version of LIST_OFFSET up 
> to 1. In this case the consumer talking to such an old broker will throw an 
> exception right away.
> What we can improve though, is that when the consumer realized broker does 
> not recognize LIST_OFFSET of at least 2, it can fall back to the old behavior 
> of READ_UNCOMMITTED since the data on that broker should not have any txn 
> markers anyways. By doing this we would lift the hard restriction that 
> consumers with READ_COMMITTED cannot work with an older version of broker 
> (remember we are trying to achieve broker compatibility since 0.10.0).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (KAFKA-7042) Fall back to the old behavior when the broker is too old to recognize LIST_OFFSET versions

2018-06-11 Thread Ismael Juma (JIRA)


[ 
https://issues.apache.org/jira/browse/KAFKA-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508768#comment-16508768
 ] 

Ismael Juma commented on KAFKA-7042:


Who is turning on READ_COMMITTED in this case?

> Fall back to the old behavior when the broker is too old to recognize 
> LIST_OFFSET versions
> --
>
> Key: KAFKA-7042
> URL: https://issues.apache.org/jira/browse/KAFKA-7042
> Project: Kafka
>  Issue Type: Improvement
>  Components: consumer
>Reporter: Guozhang Wang
>Priority: Major
>
> When READ_COMMITTED is turned on (since 0.11.0), LIST_OFFSET requires 
> min_version to be 2 on the consumer client side. On the other hand, if broker 
> is no newer than 0.10.2 it can only recognize the version of LIST_OFFSET up 
> to 1. In this case the consumer talking to such an old broker will throw an 
> exception right away.
> What we can improve though, is that when the consumer realized broker does 
> not recognize LIST_OFFSET of at least 2, it can fall back to the old behavior 
> of READ_UNCOMMITTED since the data on that broker should not have any txn 
> markers anyways. By doing this we would lift the hard restriction that 
> consumers with READ_COMMITTED cannot work with an older version of broker 
> (remember we are trying to achieve broker compatibility since 0.10.0).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (KAFKA-7042) Fall back to the old behavior when the broker is too old to recognize LIST_OFFSET versions

2018-06-11 Thread Guozhang Wang (JIRA)


[ 
https://issues.apache.org/jira/browse/KAFKA-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508761#comment-16508761
 ] 

Guozhang Wang commented on KAFKA-7042:
--

cc [~hachikuji]

> Fall back to the old behavior when the broker is too old to recognize 
> LIST_OFFSET versions
> --
>
> Key: KAFKA-7042
> URL: https://issues.apache.org/jira/browse/KAFKA-7042
> Project: Kafka
>  Issue Type: Improvement
>  Components: consumer
>Reporter: Guozhang Wang
>Priority: Major
>
> When READ_COMMITTED is turned on (since 0.11.0), LIST_OFFSET requires 
> min_version to be 2 on the consumer client side. On the other hand, if broker 
> is no newer than 0.10.2 it can only recognize the version of LIST_OFFSET up 
> to 1. In this case the consumer talking to such an old broker will throw an 
> exception right away.
> What we can improve though, is that when the consumer realized broker does 
> not recognize LIST_OFFSET of at least 2, it can fall back to the old behavior 
> of READ_UNCOMMITTED since the data on that broker should not have any txn 
> markers anyways. By doing this we would lift the hard restriction that 
> consumers with READ_COMMITTED cannot work with an older version of broker 
> (remember we are trying to achieve broker compatibility since 0.10.0).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)