[jira] [Assigned] (KAFKA-2588) ReplicaManager partitionCount metric should actually be replicaCount
[ https://issues.apache.org/jira/browse/KAFKA-2588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-2588: -- Assignee: (was: Grant Henke) > ReplicaManager partitionCount metric should actually be replicaCount > > > Key: KAFKA-2588 > URL: https://issues.apache.org/jira/browse/KAFKA-2588 > Project: Kafka > Issue Type: Bug > Components: core >Affects Versions: 0.10.0.0, 0.11.0.0, 1.0.0 >Reporter: Grant Henke >Priority: Major > Labels: needs-kip > > The metrics "partitionCount" in the ReplicaManager actually represents the > count of replicas. > As an example if I have a cluster with 1 topic with 1 partitions and a > replication factor of 3. The metric (aggregated) would show a value of 3. > There is a metric called "LeaderCount" that actually represents the > "partitionCount". In my example above the metric (aggregated) would show a > value of 1. > We do need to consider compatibility of consuming systems. I think the most > simple change would be to: > - Adjust the "partitionCount" metric to be the same value as "LeaderCount" > - Add a "replicaCount" metric which contains the values "partitionCount" does > today > - Leave "LeaderCount" in for compatibility > Documentation will need to be updated as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-1694) KIP-4: Command line and centralized operations
[ https://issues.apache.org/jira/browse/KAFKA-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-1694: -- Assignee: (was: Grant Henke) > KIP-4: Command line and centralized operations > -- > > Key: KAFKA-1694 > URL: https://issues.apache.org/jira/browse/KAFKA-1694 > Project: Kafka > Issue Type: New Feature >Reporter: Joe Stein >Priority: Critical > Attachments: KAFKA-1694.patch, KAFKA-1694_2014-12-24_21:21:51.patch, > KAFKA-1694_2015-01-12_15:28:41.patch, KAFKA-1694_2015-01-12_18:54:48.patch, > KAFKA-1694_2015-01-13_19:30:11.patch, KAFKA-1694_2015-01-14_15:42:12.patch, > KAFKA-1694_2015-01-14_18:07:39.patch, KAFKA-1694_2015-03-12_13:04:37.patch, > KAFKA-1772_1802_1775_1774_v2.patch > > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Command+Line+and+Related+Improvements -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-2620) Introduce Scalariform
[ https://issues.apache.org/jira/browse/KAFKA-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-2620: -- Assignee: (was: Grant Henke) > Introduce Scalariform > - > > Key: KAFKA-2620 > URL: https://issues.apache.org/jira/browse/KAFKA-2620 > Project: Kafka > Issue Type: Bug > Components: build >Reporter: Grant Henke >Priority: Major > > Many of our reviews include nit comments related to Scala style. Adding > [Scalariform|https://github.com/daniel-trinh/scalariform] allows us to > reformat the code based on configurable standards at build time, ensuring > uniform readability and a short review/commit cycle. > I expect this will have some discussion around the rules we would like to > include, and if we actually want to adopt this. I will submit a sample patch > to start the discussion. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-2787) Refactor gradle build
[ https://issues.apache.org/jira/browse/KAFKA-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-2787: -- Assignee: (was: Grant Henke) > Refactor gradle build > - > > Key: KAFKA-2787 > URL: https://issues.apache.org/jira/browse/KAFKA-2787 > Project: Kafka > Issue Type: Task > Components: build >Reporter: Grant Henke >Priority: Minor > > The build files are quite large with a lot of duplication and overlap. This > could lead to mistakes, reduce readability and functionality, and hinder > future changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-3603) Define HashCode and Equals methods for Schema, Field and Type
[ https://issues.apache.org/jira/browse/KAFKA-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-3603: -- Assignee: (was: Grant Henke) > Define HashCode and Equals methods for Schema, Field and Type > - > > Key: KAFKA-3603 > URL: https://issues.apache.org/jira/browse/KAFKA-3603 > Project: Kafka > Issue Type: Improvement >Reporter: Grant Henke >Priority: Major > > We should consider implementing HashCode and Equals methods for Schema, Field > and Type. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-3405) Deduplicate and break out release tasks
[ https://issues.apache.org/jira/browse/KAFKA-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-3405: -- Assignee: (was: Grant Henke) > Deduplicate and break out release tasks > --- > > Key: KAFKA-3405 > URL: https://issues.apache.org/jira/browse/KAFKA-3405 > Project: Kafka > Issue Type: Sub-task > Components: build >Reporter: Grant Henke >Priority: Minor > > Tasks like copyDependent libs are repeated throughout the build. Other tasks > like releaseTarGz should be be moved out of the core module. > While refactoring this code other optimizations like ensuring sources and > javadoc jars are not included in the classpath should be done as well. > If it makes sense, moving the release tasks to a separate gradle file is > preferred. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-3437) We don't need sitedocs package for every scala version
[ https://issues.apache.org/jira/browse/KAFKA-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-3437: -- Assignee: (was: Grant Henke) > We don't need sitedocs package for every scala version > -- > > Key: KAFKA-3437 > URL: https://issues.apache.org/jira/browse/KAFKA-3437 > Project: Kafka > Issue Type: Bug >Affects Versions: 0.9.0.0 >Reporter: Gwen Shapira >Priority: Minor > > When running "./gradlew releaseTarGzAll - it generates a binary tarball for > every scala version we support (good!) and also sitedoc tarball for every > scala version we support (useless). > Will be nice if we have a way to generate just one sitedoc tarball for our > release. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-3509) Provide an Authorizer interface using the Java client enumerator classes
[ https://issues.apache.org/jira/browse/KAFKA-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-3509: -- Assignee: (was: Grant Henke) > Provide an Authorizer interface using the Java client enumerator classes > > > Key: KAFKA-3509 > URL: https://issues.apache.org/jira/browse/KAFKA-3509 > Project: Kafka > Issue Type: Improvement >Reporter: Grant Henke >Priority: Major > > Provide an Authorizer interface using the new Java classes used by the ACL > requests/responses added as a part of KAFKA-3266. Deprecate the old one to > encourage transition. > This may require a small KIP. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-3360) Add a protocol page/section to the official Kafka documentation
[ https://issues.apache.org/jira/browse/KAFKA-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-3360: -- Assignee: (was: Grant Henke) > Add a protocol page/section to the official Kafka documentation > --- > > Key: KAFKA-3360 > URL: https://issues.apache.org/jira/browse/KAFKA-3360 > Project: Kafka > Issue Type: Improvement >Reporter: Grant Henke >Priority: Major > > This is an umbrella jira to track adding a protocol page/section to the > official Kafka documentation. It lays out subtasks for initial content and > follow up improvements and fixes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-3203) Add UnknownCodecException and UnknownMagicByteException to error mapping
[ https://issues.apache.org/jira/browse/KAFKA-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-3203: -- Assignee: (was: Grant Henke) > Add UnknownCodecException and UnknownMagicByteException to error mapping > > > Key: KAFKA-3203 > URL: https://issues.apache.org/jira/browse/KAFKA-3203 > Project: Kafka > Issue Type: Bug > Components: clients, core >Affects Versions: 0.9.0.0 >Reporter: Jiangjie Qin >Priority: Major > > Currently most of the exceptions to user have an error code. While > UnknownCodecException and UnknownMagicByteException can also be thrown to > client, broker does not have error mapping for them, so clients will only > receive UnknownServerException, which is vague. > We should create those two exceptions in client package and add them to error > mapping. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-3031) Refactor KafkaApis to be optimal for o.a.k.c requests
[ https://issues.apache.org/jira/browse/KAFKA-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-3031: -- Assignee: (was: Grant Henke) > Refactor KafkaApis to be optimal for o.a.k.c requests > - > > Key: KAFKA-3031 > URL: https://issues.apache.org/jira/browse/KAFKA-3031 > Project: Kafka > Issue Type: Sub-task >Reporter: Grant Henke >Priority: Major > > The migration changes were meant to be a minimal transition. Once most of the > migration is complete though, we should be able to refactor KafkaApis to be > more efficient, reliable and readable based on the new Requests/Responses. > An important part to handle here is the refactoring of how authorization > errors are handled generically as discussed in > https://github.com/apache/kafka/pull/196 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-3507) Define standard exceptions for the Authorizer interface
[ https://issues.apache.org/jira/browse/KAFKA-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-3507: -- Assignee: (was: Grant Henke) > Define standard exceptions for the Authorizer interface > --- > > Key: KAFKA-3507 > URL: https://issues.apache.org/jira/browse/KAFKA-3507 > Project: Kafka > Issue Type: Improvement >Affects Versions: 0.9.0.0 >Reporter: Grant Henke >Priority: Major > > The Authorizer does not define an standard exceptions that can be used by an > implementer. This means that any exception thrown on the broker, as a part of > KAFKA-3266, can only be passed back to the client as an UnknownException(-1) > making error handling difficult. A set of standard exceptions covering most > foreseeable exceptions should be defined as a part of the interface and used > in the default SimpleAclAuthorizer. > This work will require a small KIP. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-3249) Consider implementing a blocking admin requests after the initial KIP-4 work is done
[ https://issues.apache.org/jira/browse/KAFKA-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-3249: -- Assignee: (was: Grant Henke) > Consider implementing a blocking admin requests after the initial KIP-4 work > is done > > > Key: KAFKA-3249 > URL: https://issues.apache.org/jira/browse/KAFKA-3249 > Project: Kafka > Issue Type: Improvement >Reporter: Grant Henke >Priority: Major > > We have decided to make all requests/responses asynchronous in KIP-4 but see > value in adding a blocking option for admin requests in the future. This > ticket is to track that future discussion/design/work. > See the discussion here for further context: > https://github.com/apache/kafka/pull/626 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-3604) Improve error messages when null is used with a non-nullable Type
[ https://issues.apache.org/jira/browse/KAFKA-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-3604: -- Assignee: (was: Grant Henke) > Improve error messages when null is used with a non-nullable Type > - > > Key: KAFKA-3604 > URL: https://issues.apache.org/jira/browse/KAFKA-3604 > Project: Kafka > Issue Type: Improvement >Affects Versions: 0.10.0.0 >Reporter: Grant Henke >Priority: Major > > Currently when a null is passed to a non-nullable type an unclear message is > provided in the exception. We should indicate that the issue was caused by a > null value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-3610) Improve TimeoutException message when a RecordBatch expires
[ https://issues.apache.org/jira/browse/KAFKA-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-3610: -- Assignee: (was: Grant Henke) > Improve TimeoutException message when a RecordBatch expires > --- > > Key: KAFKA-3610 > URL: https://issues.apache.org/jira/browse/KAFKA-3610 > Project: Kafka > Issue Type: Improvement >Affects Versions: 0.9.0.0 >Reporter: Grant Henke >Priority: Major > > Currently when a batch expires in _RecordBatch.maybeExpire_ a Timeout > exception is throw with the message "Batch Expired". Providing some > explanation and advice on configuration options to avoid or handle the > exception would help users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-2410) Implement "Auto Topic Creation" client side and remove support from Broker side
[ https://issues.apache.org/jira/browse/KAFKA-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-2410: -- Assignee: (was: Grant Henke) > Implement "Auto Topic Creation" client side and remove support from Broker > side > --- > > Key: KAFKA-2410 > URL: https://issues.apache.org/jira/browse/KAFKA-2410 > Project: Kafka > Issue Type: Improvement > Components: clients, core >Affects Versions: 0.8.2.1 >Reporter: Grant Henke >Priority: Major > > Auto topic creation on the broker has caused pain in the past; And today it > still causes unusual error handling requirements on the client side, added > complexity in the broker, mixed responsibility of the TopicMetadataRequest, > and limits configuration of the option to be cluster wide. In the future > having it broker side will also make features such as authorization very > difficult. > There have been discussions in the past of implementing this feature client > side. > [example|https://issues.apache.org/jira/browse/KAFKA-689?focusedCommentId=13548746=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13548746] > This Jira is to track that discussion and implementation once the necessary > protocol support exists: KAFKA-2229 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-2953) Kafka documentation is really wide
[ https://issues.apache.org/jira/browse/KAFKA-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-2953: -- Assignee: (was: Grant Henke) > Kafka documentation is really wide > -- > > Key: KAFKA-2953 > URL: https://issues.apache.org/jira/browse/KAFKA-2953 > Project: Kafka > Issue Type: Bug > Components: website > Environment: Google Chrome Version 47.0.2526.73 (64-bit) >Reporter: Jens Rantil >Priority: Trivial > > The page at http://kafka.apache.org/documentation.html is extremelly wide > which is mostly annoying. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-1714) more better bootstrapping of the gradle-wrapper.jar
[ https://issues.apache.org/jira/browse/KAFKA-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-1714: -- Assignee: Grant Henke > more better bootstrapping of the gradle-wrapper.jar > > > Key: KAFKA-1714 > URL: https://issues.apache.org/jira/browse/KAFKA-1714 > Project: Kafka > Issue Type: Bug > Components: build >Affects Versions: 0.8.2.0 >Reporter: Joe Stein >Assignee: Grant Henke >Priority: Major > > From https://issues.apache.org/jira/browse/KAFKA-1490 we moved out the > gradle-wrapper.jar for our source maintenance. This makes builds for folks > coming in the first step somewhat problematic. A bootstrap step is required > if this could be somehow incorporated that would be great. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KAFKA-2124) gradlew is not working on a fresh checkout
[
https://issues.apache.org/jira/browse/KAFKA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke resolved KAFKA-2124.
Resolution: Duplicate
Assignee: Grant Henke
> gradlew is not working on a fresh checkout
> --
>
> Key: KAFKA-2124
> URL: https://issues.apache.org/jira/browse/KAFKA-2124
> Project: Kafka
> Issue Type: Bug
> Components: build
>Reporter: Jakob Homan
>Assignee: Grant Henke
>Priority: Major
>
> For a fresh checkout, the gradlew script is not working:
> {noformat}heimdallr 15:54 $ asfclone kafka
> Cloning into 'kafka'...
> remote: Counting objects: 25676, done.
> remote: Compressing objects: 100% (36/36), done.
> remote: Total 25676 (delta 5), reused 0 (delta 0), pack-reused 25627
> Receiving objects: 100% (25676/25676), 19.58 MiB | 4.29 MiB/s, done.
> Resolving deltas: 100% (13852/13852), done.
> Checking connectivity... done.
> /tmp/kafka /tmp
> /tmp
> ✔ /tmp
> heimdallr 15:54 $ cd kafka
> ✔ /tmp/kafka [trunk|✔]
> heimdallr 15:54 $ ./gradlew tasks
> Error: Could not find or load main class
> org.gradle.wrapper.GradleWrapperMain{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (KAFKA-2423) Introduce Scalastyle
[ https://issues.apache.org/jira/browse/KAFKA-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke reassigned KAFKA-2423: -- Assignee: Ray Chiang (was: Grant Henke) > Introduce Scalastyle > > > Key: KAFKA-2423 > URL: https://issues.apache.org/jira/browse/KAFKA-2423 > Project: Kafka > Issue Type: Improvement >Reporter: Ismael Juma >Assignee: Ray Chiang >Priority: Major > > This is similar to Checkstyle (which we already use), but for Scala: > http://www.scalastyle.org/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KAFKA-4906) Support 0.9 brokers with a newer Producer or Consumer version
[
https://issues.apache.org/jira/browse/KAFKA-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke resolved KAFKA-4906.
Resolution: Won't Fix
> Support 0.9 brokers with a newer Producer or Consumer version
> -
>
> Key: KAFKA-4906
> URL: https://issues.apache.org/jira/browse/KAFKA-4906
> Project: Kafka
> Issue Type: Improvement
> Components: clients
>Affects Versions: 0.10.2.0
>Reporter: Grant Henke
>Assignee: Grant Henke
>
> KAFKA-4507 added the ability for newer Kafka clients to talk to older Kafka
> brokers if a new feature supported by a newer wire protocol was not
> used/required.
> We currently support brokers as old as 0.10.0.0 because thats when the
> ApiVersionsRequest/Response was added to the broker (KAFKA-3307).
> However, there are relatively few changes between 0.9.0.0 and 0.10.0.0 on the
> wire, making it possible to support another major broker version set by
> assuming that any disconnect resulting from an ApiVersionsRequest is from a
> 0.9 broker and defaulting to legacy protocol versions.
> Supporting 0.9 with newer clients can drastically simplify upgrades, allow
> for libraries and frameworks to easily support a wider set of environments,
> and let developers take advantage of client side improvements without
> requiring cluster upgrades first.
> Below is a list of the wire protocol versions by release for reference:
> {noformat}
> 0.10.x
> Produce(0): 0 to 2
> Fetch(1): 0 to 2
> Offsets(2): 0
> Metadata(3): 0 to 1
> OffsetCommit(8): 0 to 2
> OffsetFetch(9): 0 to 1
> GroupCoordinator(10): 0
> JoinGroup(11): 0
> Heartbeat(12): 0
> LeaveGroup(13): 0
> SyncGroup(14): 0
> DescribeGroups(15): 0
> ListGroups(16): 0
> SaslHandshake(17): 0
> ApiVersions(18): 0
> 0.9.x:
> Produce(0): 0 to 1 (no response timestamp from v2)
> Fetch(1): 0 to 1 (no response timestamp from v2)
> Offsets(2): 0
> Metadata(3): 0 (no cluster id or rack info from v1)
> OffsetCommit(8): 0 to 2
> OffsetFetch(9): 0 to 1
> GroupCoordinator(10): 0
> JoinGroup(11): 0
> Heartbeat(12): 0
> LeaveGroup(13): 0
> SyncGroup(14): 0
> DescribeGroups(15): 0
> ListGroups(16): 0
> SaslHandshake(17): UNSUPPORTED
> ApiVersions(18): UNSUPPORTED
> 0.8.2.x:
> Produce(0): 0 (no quotas from v1)
> Fetch(1): 0 (no quotas from v1)
> Offsets(2): 0
> Metadata(3): 0
> OffsetCommit(8): 0 to 1 (no global retention time from v2)
> OffsetFetch(9): 0 to 1
> GroupCoordinator(10): 0
> JoinGroup(11): UNSUPPORTED
> Heartbeat(12): UNSUPPORTED
> LeaveGroup(13): UNSUPPORTED
> SyncGroup(14): UNSUPPORTED
> DescribeGroups(15): UNSUPPORTED
> ListGroups(16): UNSUPPORTED
> SaslHandshake(17): UNSUPPORTED
> ApiVersions(18): UNSUPPORTED
> {noformat}
> Note: Due to KAFKA-3088 it may take up to request.timeout.time to fail an
> ApiVersionsRequest and failover to legacy protocol versions unless we handle
> that scenario specifically in this patch. The workaround would be to reduce
> request.timeout.time if needed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KAFKA-3268) Refactor existing CLI scripts to use new AdminClient
[ https://issues.apache.org/jira/browse/KAFKA-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080385#comment-16080385 ] Grant Henke commented on KAFKA-3268: Not at all. Feel free. > Refactor existing CLI scripts to use new AdminClient > > > Key: KAFKA-3268 > URL: https://issues.apache.org/jira/browse/KAFKA-3268 > Project: Kafka > Issue Type: Sub-task >Reporter: Grant Henke > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
