Re: [DISCUSS] KIP-43: Kafka SASL enhancements

Harsha, You are right, we don't expect to override callback handler or login for Digest-MD5. Pluggable CallbackHandler and Login modules enable custom SASL mechanisms to be implemented without modifying Kafka. For instance, it would enable KIP-44 ( https://cwiki.apache.org/confluence/display/KAFK

[jira] [Commented] (KAFKA-2165) ReplicaFetcherThread: data loss on unknown exception

[ https://issues.apache.org/jira/browse/KAFKA-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192931#comment-15192931 ] jiang tao commented on KAFKA-2165: -- @Jun Rao Recently,our production cluster have sudden

[jira] [Reopened] (KAFKA-2165) ReplicaFetcherThread: data loss on unknown exception

[ https://issues.apache.org/jira/browse/KAFKA-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma reopened KAFKA-2165: > ReplicaFetcherThread: data loss on unknown exception > ---

[jira] [Resolved] (KAFKA-2165) ReplicaFetcherThread: data loss on unknown exception

[ https://issues.apache.org/jira/browse/KAFKA-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma resolved KAFKA-2165. Resolution: Duplicate > ReplicaFetcherThread: data loss on unknown exception > -

[jira] [Commented] (KAFKA-2165) ReplicaFetcherThread: data loss on unknown exception

[ https://issues.apache.org/jira/browse/KAFKA-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192948#comment-15192948 ] Ismael Juma commented on KAFKA-2165: I changed the resolution to duplicate of KAFKA-21

[jira] [Resolved] (KAFKA-2551) Unclean leader election docs outdated

[ https://issues.apache.org/jira/browse/KAFKA-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manikumar Reddy resolved KAFKA-2551. Resolution: Fixed > Unclean leader election docs outdated >

[jira] [Work started] (KAFKA-3188) Add system test for KIP-31 and KIP-32 - Compatibility Test

[ https://issues.apache.org/jira/browse/KAFKA-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KAFKA-3188 started by Eno Thereska. --- > Add system test for KIP-31 and KIP-32 - Compatibility Test >

[jira] [Commented] (KAFKA-493) High CPU usage on inactive server

[ https://issues.apache.org/jira/browse/KAFKA-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193245#comment-15193245 ] Cosmin Marginean commented on KAFKA-493: Thanks Andrew. Will do this in the next fe

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Hi Ashish, A few comments below. On Fri, Mar 11, 2016 at 9:59 PM, Ashish Singh wrote: > Sounds like we are mostly in agreement. Following are the key points. > >1. Every time a protocol version changes, for any request/response, >broker version, ApiVersion, will be bumped up. > Any tho

[GitHub] kafka pull request: MINOR: Review change to block.on.buffer.full c...

GitHub user granthenke opened a pull request: https://github.com/apache/kafka/pull/1058 MINOR: Review change to block.on.buffer.full config You can merge this pull request into a Git repository by running: $ git pull https://github.com/granthenke/kafka block-on-buffer-full Al

[jira] [Commented] (KAFKA-3388) Producer should only timeout a batch in the accumulator when metadata is missing.

[ https://issues.apache.org/jira/browse/KAFKA-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193448#comment-15193448 ] Mayuresh Gharat commented on KAFKA-3388: If the batch is retried and re-enqueued,

[jira] [Assigned] (KAFKA-3390) ReplicaManager may infinitely try-fail to shrink ISR set of deleted partition

[ https://issues.apache.org/jira/browse/KAFKA-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mayuresh Gharat reassigned KAFKA-3390: -- Assignee: Mayuresh Gharat > ReplicaManager may infinitely try-fail to shrink ISR set of

[jira] [Updated] (KAFKA-3248) AdminClient Blocks Forever in send Method

[ https://issues.apache.org/jira/browse/KAFKA-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3248: --- Status: Patch Available (was: Open) > AdminClient Blocks Forever in send Method > ---

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 7:05 AM, Ismael Juma wrote: > Hi Ashish, > > A few comments below. > > On Fri, Mar 11, 2016 at 9:59 PM, Ashish Singh wrote: > >> Sounds like we are mostly in agreement. Following are the key points. >> >>1. Every time a protocol version changes, for any request/respons

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Hi Gwen, On Mon, Mar 14, 2016 at 4:37 PM, Gwen Shapira wrote: > On Mon, Mar 14, 2016 at 7:05 AM, Ismael Juma wrote:> > >>1. Every time a protocol version changes, for any request/response, > >>broker version, ApiVersion, will be bumped up. > >> > > > > Any thoughts on how we will enforc

[jira] [Created] (KAFKA-3393) Update site docs and javadoc based on max.block.ms changes

Grant Henke created KAFKA-3393: -- Summary: Update site docs and javadoc based on max.block.ms changes Key: KAFKA-3393 URL: https://issues.apache.org/jira/browse/KAFKA-3393 Project: Kafka Issue Ty

[GitHub] kafka pull request: KAFKA-3188: Compatibility test for old and new...

GitHub user enothereska opened a pull request: https://github.com/apache/kafka/pull/1059 KAFKA-3188: Compatibility test for old and new clients with 0.10 broker @apovzner @becketqin please have a look if you can. Thanks. You can merge this pull request into a Git repository by runni

[jira] [Commented] (KAFKA-3188) Add system test for KIP-31 and KIP-32 - Compatibility Test

[ https://issues.apache.org/jira/browse/KAFKA-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193689#comment-15193689 ] ASF GitHub Bot commented on KAFKA-3188: --- GitHub user enothereska opened a pull reque

[jira] [Work started] (KAFKA-3202) Add system test for KIP-31 and KIP-32 - Change message format version on the fly

[ https://issues.apache.org/jira/browse/KAFKA-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KAFKA-3202 started by Eno Thereska. --- > Add system test for KIP-31 and KIP-32 - Change message format version on the > f

[Reminder] 0.10.0 release candidate coming up in a week!

Hey Team, Just a reminder, we are planning to roll out the first release candidate for 0.10.0 in exactly one week. According to our release plan ( https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+0.10.0), we have 13 open blockers (up from 12 on Thursday). Here's the list: KeySummar

[jira] [Commented] (KAFKA-3367) Delete topic dont delete the complete log from kafka

[ https://issues.apache.org/jira/browse/KAFKA-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193801#comment-15193801 ] Akshath Patkar commented on KAFKA-3367: --- Thanks [~mgharat] will close this issue for

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Hello Gwen/ Ismael, On Mon, Mar 14, 2016 at 9:55 AM, Ismael Juma wrote: > Hi Gwen, > > On Mon, Mar 14, 2016 at 4:37 PM, Gwen Shapira wrote: > > > On Mon, Mar 14, 2016 at 7:05 AM, Ismael Juma wrote:> > > >>1. Every time a protocol version changes, for any request/response, > > >>broker

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 9:37 AM, Gwen Shapira wrote: > On Mon, Mar 14, 2016 at 7:05 AM, Ismael Juma wrote: > > Hi Ashish, > > > > A few comments below. > > > > On Fri, Mar 11, 2016 at 9:59 PM, Ashish Singh > wrote: > > > >> Sounds like we are mostly in agreement. Following are the key points. >

[jira] [Commented] (KAFKA-2464) Client-side assignment and group generalization

[ https://issues.apache.org/jira/browse/KAFKA-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193852#comment-15193852 ] Jason Gustafson commented on KAFKA-2464: [~becket_qin] Looks like I missed this re

Re: [DISCUSS] KIP-35 - Retrieve protocol version

There seems to be a lot of tension between support for release-deploys vs. trunk-deploys. Is there a better way to handle this? In my experience the vast majority of third-party client code is written managing compatibility on the first case (release-deploys). I would prefer a simple approach that

[GitHub] kafka pull request: KAFKA-3393 : Updated the docs to reflect the d...

GitHub user MayureshGharat opened a pull request: https://github.com/apache/kafka/pull/1060 KAFKA-3393 : Updated the docs to reflect the deprecation of block.on.buffer.full and usage of max.block.ms You can merge this pull request into a Git repository by running: $ git pull

[jira] [Commented] (KAFKA-3393) Update site docs and javadoc based on max.block.ms changes

[ https://issues.apache.org/jira/browse/KAFKA-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193877#comment-15193877 ] ASF GitHub Bot commented on KAFKA-3393: --- GitHub user MayureshGharat opened a pull re

[GitHub] kafka pull request: TRIVIAL: remove TODO in ConsumerNetworkClient ...

GitHub user christian-posta opened a pull request: https://github.com/apache/kafka/pull/1061 TRIVIAL: remove TODO in ConsumerNetworkClient after KAFKA-2120 You can merge this pull request into a Git repository by running: $ git pull https://github.com/christian-posta/kafka ce

[jira] [Commented] (KAFKA-2120) Add a request timeout to NetworkClient

[ https://issues.apache.org/jira/browse/KAFKA-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193917#comment-15193917 ] ASF GitHub Bot commented on KAFKA-2120: --- GitHub user christian-posta opened a pull r

[jira] [Created] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

Magnus Edenhill created KAFKA-3394: -- Summary: Broker fails to parse Null Metadata in OffsetCommit requests Key: KAFKA-3394 URL: https://issues.apache.org/jira/browse/KAFKA-3394 Project: Kafka

[jira] [Updated] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

[ https://issues.apache.org/jira/browse/KAFKA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3394: --- Fix Version/s: 0.10.0.0 > Broker fails to parse Null Metadata in OffsetCommit requests > -

[jira] [Updated] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

[ https://issues.apache.org/jira/browse/KAFKA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3394: --- Priority: Blocker (was: Major) > Broker fails to parse Null Metadata in OffsetCommit requests > -

[jira] [Commented] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

[ https://issues.apache.org/jira/browse/KAFKA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194032#comment-15194032 ] Ismael Juma commented on KAFKA-3394: This is a regression caused by changing `KafkaApi

[jira] [Assigned] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

[ https://issues.apache.org/jira/browse/KAFKA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gustafson reassigned KAFKA-3394: -- Assignee: Jason Gustafson > Broker fails to parse Null Metadata in OffsetCommit request

[GitHub] kafka pull request: MINOR: Review change to block.on.buffer.full c...

Github user granthenke closed the pull request at: https://github.com/apache/kafka/pull/1058 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[jira] [Updated] (KAFKA-3338) Add print / writeAsTex / etc functions to the DSL

[ https://issues.apache.org/jira/browse/KAFKA-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang updated KAFKA-3338: - Priority: Major (was: Blocker) > Add print / writeAsTex / etc functions to the DSL >

[jira] [Commented] (KAFKA-3338) Add print / writeAsTex / etc functions to the DSL

[ https://issues.apache.org/jira/browse/KAFKA-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194044#comment-15194044 ] Guozhang Wang commented on KAFKA-3338: -- [~gwenshap] Down grading to major as this may

[jira] [Updated] (KAFKA-3337) Extract selector as a separate groupBy operator for KTable aggregations

[ https://issues.apache.org/jira/browse/KAFKA-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang updated KAFKA-3337: - Priority: Major (was: Blocker) > Extract selector as a separate groupBy operator for KTable aggre

[jira] [Commented] (KAFKA-3337) Extract selector as a separate groupBy operator for KTable aggregations

[ https://issues.apache.org/jira/browse/KAFKA-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194046#comment-15194046 ] Guozhang Wang commented on KAFKA-3337: -- [~gwenshap] Down grading to major as it may n

[jira] [Created] (KAFKA-3395) prefix job id to internal topic names

Yasuhiro Matsuda created KAFKA-3395: --- Summary: prefix job id to internal topic names Key: KAFKA-3395 URL: https://issues.apache.org/jira/browse/KAFKA-3395 Project: Kafka Issue Type: Sub-tas

[GitHub] kafka pull request: KAFKA-3395: prefix job id to internal topic na...

GitHub user ymatsuda opened a pull request: https://github.com/apache/kafka/pull/1062 KAFKA-3395: prefix job id to internal topic names @guozhangwang You can merge this pull request into a Git repository by running: $ git pull https://github.com/ymatsuda/kafka k3395 Alternat

[jira] [Commented] (KAFKA-3395) prefix job id to internal topic names

[ https://issues.apache.org/jira/browse/KAFKA-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194051#comment-15194051 ] ASF GitHub Bot commented on KAFKA-3395: --- GitHub user ymatsuda opened a pull request:

[jira] [Commented] (KAFKA-2464) Client-side assignment and group generalization

[ https://issues.apache.org/jira/browse/KAFKA-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194053#comment-15194053 ] Jiangjie Qin commented on KAFKA-2464: - Thanks, sounds good. I don't think there will b

Re: KStreams Proposal

Thanks Bill for the detailed description of your use case. I think part of the issue is that today KStream does not allow non-keyed aggregation, and hence users need to call a `map` function if they want to do aggregations on other fields. We did this by design for KStream since if users write the

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Hi Ashish, Comments inline. On Mon, Mar 14, 2016 at 6:15 PM, Ashish Singh wrote: > I think ApiVersion aims to identify protocol version changes, more than > release change, > > https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/api/ApiVersion.scala#L30 > . > That is something

Kafka KIP meeting Mar 15 at 11:00am PST

Hi, Everyone, We will have a Kafka KIP meeting tomorrow at 11:00am PST. If you plan to attend but haven't received an invite, please let me know. The following is the agenda. Agenda: KIP-35 - Retrieving protocol version KIP-45 - Standardize all client sequence interaction on j.u.Collection KIP-3

[jira] [Commented] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

[ https://issues.apache.org/jira/browse/KAFKA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194089#comment-15194089 ] Grant Henke commented on KAFKA-3394: This could happen for basically any string in the

Re: [DISCUSS] KIP-35 - Retrieve protocol version

> > > I don't see how it helps. If the client is communicating with a broker that > does not support KIP-35, that broker will simply close the connection. If > the broker supports KIP-35, then it will provide the broker version. I > don't envisage a scenario where a broker does not support KIP-35,

[jira] [Commented] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

[ https://issues.apache.org/jira/browse/KAFKA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194116#comment-15194116 ] Jason Gustafson commented on KAFKA-3394: [~granthenke] I considered this when I fi

[jira] [Commented] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

[ https://issues.apache.org/jira/browse/KAFKA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194134#comment-15194134 ] Grant Henke commented on KAFKA-3394: [~hachikuji] I agree that allowing nulls everywhe

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 8:45 PM, Gwen Shapira wrote: > > > I don't see how it helps. If the client is communicating with a broker > that > > does not support KIP-35, that broker will simply close the connection. If > > the broker supports KIP-35, then it will provide the broker version. I > > don'

[jira] [Commented] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

[ https://issues.apache.org/jira/browse/KAFKA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194152#comment-15194152 ] Ismael Juma commented on KAFKA-3394: Given how the Scala request classes work, it seem

[jira] [Commented] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

[ https://issues.apache.org/jira/browse/KAFKA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194157#comment-15194157 ] Jason Gustafson commented on KAFKA-3394: Yeah, I guess what I was thinking is whet

[jira] [Created] (KAFKA-3396) Unauthorized topics are returned to the user

Grant Henke created KAFKA-3396: -- Summary: Unauthorized topics are returned to the user Key: KAFKA-3396 URL: https://issues.apache.org/jira/browse/KAFKA-3396 Project: Kafka Issue Type: Bug

[jira] [Assigned] (KAFKA-3336) Unify ser/de pair classes into one serde class

[ https://issues.apache.org/jira/browse/KAFKA-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang reassigned KAFKA-3336: Assignee: Guozhang Wang > Unify ser/de pair classes into one serde class >

[jira] [Updated] (KAFKA-3336) Unify ser/de pair classes into one serde class

[ https://issues.apache.org/jira/browse/KAFKA-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang updated KAFKA-3336: - Description: Right now users must provide two separate classes for serializers and deserializers,

[jira] [Updated] (KAFKA-3336) Unify ser/de pair classes into one serde class

[ https://issues.apache.org/jira/browse/KAFKA-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang updated KAFKA-3336: - Description: Right now users must provide two separate classes for serializers and deserializers,

[GitHub] kafka pull request: KAFKA-3395: prefix job id to internal topic na...

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/1062 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enab

[jira] [Updated] (KAFKA-3395) prefix job id to internal topic names

[ https://issues.apache.org/jira/browse/KAFKA-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang updated KAFKA-3395: - Assignee: Yasuhiro Matsuda > prefix job id to internal topic names > -

[jira] [Resolved] (KAFKA-3395) prefix job id to internal topic names

[ https://issues.apache.org/jira/browse/KAFKA-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang resolved KAFKA-3395. -- Resolution: Fixed Issue resolved by pull request 1062 [https://github.com/apache/kafka/pull/1062

[jira] [Commented] (KAFKA-3395) prefix job id to internal topic names

[ https://issues.apache.org/jira/browse/KAFKA-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194224#comment-15194224 ] ASF GitHub Bot commented on KAFKA-3395: --- Github user asfgit closed the pull request

[GitHub] kafka pull request: [MINOR] cleanup

GitHub user Ishiihara opened a pull request: https://github.com/apache/kafka/pull/1063 [MINOR] cleanup @guozhangwang Very minor cleanup. You can merge this pull request into a Git repository by running: $ git pull https://github.com/Ishiihara/kafka minor-cleanup Alternatively

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Agree. Regardless of which one of us understood the KIP correctly, this kind of thing should be crystal clear in the KIP. On Mon, Mar 14, 2016 at 2:12 PM, Ismael Juma wrote: > On Mon, Mar 14, 2016 at 8:45 PM, Gwen Shapira wrote: > > > > > I don't see how it helps. If the client is communicating

KIP-4 Wiki Update

I have been updating the KIP-4 wiki page based on the last KIP call and wanted to get some review and discussion around the server side implementation for admin requests. Both the "ideal" functionality and the "intermediated" functionality. The updates are still in progress, but this section is the

[jira] [Commented] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

[ https://issues.apache.org/jira/browse/KAFKA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194269#comment-15194269 ] ASF GitHub Bot commented on KAFKA-3394: --- GitHub user hachikuji opened a pull request

[GitHub] kafka pull request: [MINOR]: Remove unused method, redundant in in...

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/1063 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enab

[GitHub] kafka pull request: KAFKA-3394: allow null offset metadata in comm...

GitHub user hachikuji opened a pull request: https://github.com/apache/kafka/pull/1064 KAFKA-3394: allow null offset metadata in commit API You can merge this pull request into a Git repository by running: $ git pull https://github.com/hachikuji/kafka KAFKA-3394 Alternatively

[GitHub] kafka pull request: MINOR: kstream/ktable counting method with def...

GitHub user ymatsuda opened a pull request: https://github.com/apache/kafka/pull/1065 MINOR: kstream/ktable counting method with default long serdes @guozhangwang @miguno You can merge this pull request into a Git repository by running: $ git pull https://github.com/ymatsuda/k

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 2:12 PM, Ismael Juma wrote: > On Mon, Mar 14, 2016 at 8:45 PM, Gwen Shapira wrote: > > > > > I don't see how it helps. If the client is communicating with a broker > > that > > > does not support KIP-35, that broker will simply close the connection. > If > > > the broker

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 7:05 AM, Ismael Juma wrote: > Hi Ashish, > > A few comments below. > > On Fri, Mar 11, 2016 at 9:59 PM, Ashish Singh wrote: > > > Sounds like we are mostly in agreement. Following are the key points. > > > >1. Every time a protocol version changes, for any request/res

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 10:35 PM, Ashish Singh wrote: > > Also, I think it's a bit odd to say a `single null topic with size -1`. > Do > > we mean an array of topics with size -1 and no elements? That would imply > > introducing a NULLABLE_ARRAY type (we currently have NULLABLE_STRING and > > NUL

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 3:37 PM, Ismael Juma wrote: > On Mon, Mar 14, 2016 at 10:35 PM, Ashish Singh > wrote: > > > > Also, I think it's a bit odd to say a `single null topic with size -1`. > > Do > > > we mean an array of topics with size -1 and no elements? That would > imply > > > introducing

Re: [DISCUSS] KIP-35 - Retrieve protocol version

I have updated the KIP based on the discussions so far. Will initiate a VOTE thread soon. There are some minor details that are still under discussion, but nothing major to stop us from voting. On Mon, Mar 14, 2016 at 3:39 PM, Ashish Singh wrote: > > > On Mon, Mar 14, 2016 at 3:37 PM, Ismael Jum

[VOTE] KIP-35: Retrieving protocol version

Hey Guys, I would like to start voting process for *KIP-35: Retrieving protocol version*. The KIP is available here . Here

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Perhaps clients should always send the oldest version of the metadata request which supports KIP-35 when initially connecting to the cluster. Depending on the versions in the response, it can upgrade to a more recent version. Then maybe we don't need the empty response hack? One thing that's not c

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Hi Jason, On Mon, Mar 14, 2016 at 4:04 PM, Jason Gustafson wrote: > Perhaps clients should always send the oldest version of the metadata > request which supports KIP-35 when initially connecting to the cluster. > Depending on the versions in the response, it can upgrade to a more recent > versi

Re: [DISCUSS] KIP-35 - Retrieve protocol version

> > Are you suggesting this as a solution for the problem where a KIP-35 aware > client sends a higher version of metadata req, say v2, to a KIP-35 aware > broker that only supports up to v1. Yes, that's right. In that case, the client first sends v1, finds out that the broker supports v2, and th

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 4:51 PM, Jason Gustafson wrote: > > > > Are you suggesting this as a solution for the problem where a KIP-35 > aware > > client sends a higher version of metadata req, say v2, to a KIP-35 aware > > broker that only supports up to v1. > > > Yes, that's right. In that case,

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Couple of missing things: This KIP doesn't have a proposal on versioning it just gives different options, it'd be good to get a concrete proposal in the KIP. Here is my understanding of what we are proposing (can someone sanity check and if correct, update the kip): 1. We will augment the exis

Jenkins build is back to normal : kafka-trunk-jdk7 #1114

See

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 5:31 PM, Jay Kreps wrote: > Couple of missing things: > > This KIP doesn't have a proposal on versioning it just gives different > options, it'd be good to get a concrete proposal in the KIP. Here is my > understanding of what we are proposing (can someone sanity check and

Build failed in Jenkins: kafka-trunk-jdk8 #442

See Changes: [wangguoz] KAFKA-3395: prefix job id to internal topic names [wangguoz] MINOR: Remove unused method, redundant in interface definition and add -- [...truncated 3615 lines...] org.

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Yeah I think that is the point--we have a proposal for a new protocol versioning scheme and a vote on it but it doesn't actually describe how versioning will work yet! I gave my vague impression based on this thread, but I want to make sure that is correct and get it written down before we adopt it

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Is a linear protocol int consistent with the current release model? It seems like that would break down w/ the multiple release branches that are all simultaneously maintained? Or is it implicit that no patch release can ever bump the protocol int? Or maybe the protocol int gets some extra "wiggle"

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Thats a great point, Dana. Thanks for bringing this up. Ewen raised the same concern and suggested something called "feature detection" where the broker would advertise support for specific features that clients may need and by that avoid a linear model (it also allows for advertising features suc

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Hey Dana, I am actually thinking about it differently. Basically I think you are imagining a world in which the Kafka code is the source of truth, and the Kafka developers make random changes that inflict pain on you at will. The protocol documentation is basically just some semi-accurate descript

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Jay, Ewen had a good example: 1. 0.10.0 (protocol v4) is released with current KIP-35 2. On trunk, modify produce requests and bump to v5 3. On trunk, we modify metadata requests and bump to v6 4. Now we decide that the metadata change fixes a super critical issue and want to backport the change

[GitHub] kafka pull request: KAFKA-3336: Unify Serializer and Deserializer ...

GitHub user guozhangwang opened a pull request: https://github.com/apache/kafka/pull/1066 KAFKA-3336: Unify Serializer and Deserializer into Serialization You can merge this pull request into a Git repository by running: $ git pull https://github.com/guozhangwang/kafka K3336

[jira] [Commented] (KAFKA-3336) Unify ser/de pair classes into one serde class

[ https://issues.apache.org/jira/browse/KAFKA-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194545#comment-15194545 ] ASF GitHub Bot commented on KAFKA-3336: --- GitHub user guozhangwang opened a pull requ

[GitHub] kafka pull request: KAFKA-2982; Mark the old Scala producer and re...

GitHub user ijuma opened a pull request: https://github.com/apache/kafka/pull/1067 KAFKA-2982; Mark the old Scala producer and related classes as deprecated You can merge this pull request into a Git repository by running: $ git pull https://github.com/ijuma/kafka kafka-2982-d

[jira] [Commented] (KAFKA-2982) Mark the old Scala producer and related classes as deprecated

[ https://issues.apache.org/jira/browse/KAFKA-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194549#comment-15194549 ] ASF GitHub Bot commented on KAFKA-2982: --- GitHub user ijuma opened a pull request:

[jira] [Updated] (KAFKA-2982) Mark the old Scala producer and related classes as deprecated

[ https://issues.apache.org/jira/browse/KAFKA-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-2982: --- Status: Patch Available (was: In Progress) > Mark the old Scala producer and related classes as depre

[jira] [Created] (KAFKA-3397) add missing 'REQUIRED' for tools.GetOffsetShell

Xin Wang created KAFKA-3397: --- Summary: add missing 'REQUIRED' for tools.GetOffsetShell Key: KAFKA-3397 URL: https://issues.apache.org/jira/browse/KAFKA-3397 Project: Kafka Issue Type: Bug

[GitHub] kafka pull request: KAFKA-3373 add 'log' prefix to configurations ...

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/1049 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enab

[jira] [Updated] (KAFKA-3373) Add `log` prefix to KIP-31/32 configs

[ https://issues.apache.org/jira/browse/KAFKA-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gwen Shapira updated KAFKA-3373: Resolution: Fixed Status: Resolved (was: Patch Available) Issue resolved by pull request 10

[GitHub] kafka pull request: KAFKA-3375; Suppress deprecated warnings where...

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/1042 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enab

[jira] [Updated] (KAFKA-3375) Suppress and fix compiler warnings where reasonable and tweak compiler settings

[ https://issues.apache.org/jira/browse/KAFKA-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gwen Shapira updated KAFKA-3375: Resolution: Fixed Status: Resolved (was: Patch Available) Issue resolved by pull request 10

[jira] [Commented] (KAFKA-3375) Suppress and fix compiler warnings where reasonable and tweak compiler settings

[ https://issues.apache.org/jira/browse/KAFKA-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194580#comment-15194580 ] ASF GitHub Bot commented on KAFKA-3375: --- Github user asfgit closed the pull request

[jira] [Commented] (KAFKA-3373) Add `log` prefix to KIP-31/32 configs

[ https://issues.apache.org/jira/browse/KAFKA-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194577#comment-15194577 ] ASF GitHub Bot commented on KAFKA-3373: --- Github user asfgit closed the pull request

[GitHub] kafka pull request: KAFKA-3013

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/695 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabl

  1   2   >