kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-4635) Client Compatibility follow-up
Date Fri, 20 Jan 2017 23:32:26 GMT

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

ASF GitHub Bot commented on KAFKA-4635:
---------------------------------------

GitHub user cmccabe opened a pull request:

    https://github.com/apache/kafka/pull/2414

    KAFKA-4635: Client Compatibility follow-ups

    

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/cmccabe/kafka KAFKA-4635

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/kafka/pull/2414.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 #2414
    
----
commit f3db4b0edc6a50a608c9876573ce6adbb1e5f378
Author: Colin P. Mccabe <cmccabe@confluent.io>
Date:   2017-01-20T22:59:26Z

    ObsoleteBrokerException -> OutdatedBrokerException, revise comment for OffsetAndTimestamp

commit b39db596d5f0aab7dea31fce0edf7e88cf2bf2a9
Author: Colin P. Mccabe <cmccabe@confluent.io>
Date:   2017-01-20T23:09:38Z

    Add debug log message when downgrading the message protocol for an older broker

commit 6414fa18f7c695c1801aa93adf6a3a5bc9815d7b
Author: Colin P. Mccabe <cmccabe@confluent.io>
Date:   2017-01-20T23:23:07Z

    NodeApiVersionsTest: add more tests

commit b38c79d6129ed76cf73868766765516ab9f3731e
Author: Colin P. Mccabe <cmccabe@confluent.io>
Date:   2017-01-20T23:30:03Z

    docs/upgrade.html: add a paragraph about client compatibility in 0.10.2

----


> Client Compatibility follow-up
> ------------------------------
>
>                 Key: KAFKA-4635
>                 URL: https://issues.apache.org/jira/browse/KAFKA-4635
>             Project: Kafka
>          Issue Type: Sub-task
>          Components: clients
>            Reporter: Ismael Juma
>            Assignee: Colin P. McCabe
>             Fix For: 0.10.2.0
>
>
> I collected a number of improvements that I think would be good to do before the release.
[~cmccabe], please correct if I got anything wrong and feel free to move some items to separate
JIRAs.
> 1. OffsetAndTimestamp is a public class and the javadoc should only include the behaviour
that users will see. The following (or part of it) should probably be a non-javadoc comment
as it only happens internally:
> "* The timestamp should never be negative, unless it is invalid.  This could happen when
handling a response from a broker that doesn't support KIP-79."
> 2. There was a bit of a discussion with regards to the name of the exception that is
thrown when a broker is too old. The current name is ObsoleteBrokerException. We should decide
on the name and then we should update the relevant producer/consumer methods to mention it.
> 3. [~junrao] suggested that it would be a good idea log when downgrading requests as
the behaviour can be a little different. We should decide the right logging level and add
this.
> 4. We should have a system test against 0.9.0.1 brokers. We don't support it, but we
should ideally give a reasonable error message.
> 5. It seems like `Fetcher.listOffset` could use `retrieveOffsetsByTimes` instead of calling
`sendListOffsetRequests` directly. I think that would be a little better, but not sure if
others disagree.
> 6. [~hachikuji] suggested that a version mismatch in the `offsetsForTimes` call should
result in null entry in map instead of exception for consistency with how we handle the unsupported
message format case. I am adding this to make sure we discuss it, but I am not actually sure
that is what we should do. Under normal circumstances, the brokers are either too old or not
whereas the message format is a topic level configuration and, strictly speaking, independent
of the broker version (there is a correlation in practice).
> 7. We log a warning in case of an error while doing an ApiVersions request. Because it
is the first request and we retry, the warning in the log is useful. We have a similar warning
for Metadata requests, but we only did it for bootstrap brokers. Would it make sense to do
the same for ApiVersions?
> 8. It would be good to add a few more tests for the usable versions computation. We have
a single simple one at the moment.
> 9. We should add a note to the upgrade notes specifying the change in behaviour with
regards to older broker versions.
> cc [~hachikuji].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message