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

I think there is a bit of misunderstanding going on here regarding protocol documentation and its versioning. It could be that I am the one who misunderstood it, please correct me if so. Taking Gwen's example. 1. 0.10.0 (protocol v4) is released with current KIP-35 2. On trunk, modify produce re

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

Yeah, Gwen's example is a good one. And it doesn't even have to be thought of in terms of the implementation -- you can think of the protocol itself as effectively being possible to branch and have changes cherry-picked. Given the way some changes interact and that only some may be feasible to back

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

I have been following this thread with some interest over the past couple of days especially since we run off trunk for the most part. I have been on the fence on the approach of a global API version (which we did come up in the original KIP discussion). I think what everyone felt at the time was a

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

Again I think that implies a world view where the code is the source of truth. What I'm proposing, though is that there are only protocol versions 5 and version 6 as defined by the protocol spec and you either support 6 or you don't, supporting part of 6 is just being an incorrect implementation of

[jira] [Updated] (KAFKA-3316) Add Connect REST API to list available connector classes

[ https://issues.apache.org/jira/browse/KAFKA-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ewen Cheslack-Postava updated KAFKA-3316: - Assignee: Liquan Pei (was: Ewen Cheslack-Postava) > Add Connect REST API to list

Jenkins build is back to normal : kafka-trunk-jdk8 #443

See

[jira] [Updated] (KAFKA-3398) avoid just sending to one partition when record key is empty string

[ https://issues.apache.org/jira/browse/KAFKA-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xin Wang updated KAFKA-3398: Description: Now the DefaultPartitioner, if record key==null, choose a partition in a round-robin fashion; e

[jira] [Commented] (KAFKA-3398) avoid just sending to one partition when record key is empty string

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

[GitHub] kafka pull request: KAFKA-3398: avoid just sending to one partitio...

GitHub user vesense opened a pull request: https://github.com/apache/kafka/pull/1069 KAFKA-3398: avoid just sending to one partition when record key is empty string You can merge this pull request into a Git repository by running: $ git pull https://github.com/vesense/kafka p

[jira] [Created] (KAFKA-3398) avoid just sending to one partition when record key is empty string

Xin Wang created KAFKA-3398: --- Summary: avoid just sending to one partition when record key is empty string Key: KAFKA-3398 URL: https://issues.apache.org/jira/browse/KAFKA-3398 Project: Kafka Issu

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

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

[GitHub] kafka pull request: KAFKA-3397: add missing 'REQUIRED' for tools.G...

GitHub user vesense opened a pull request: https://github.com/apache/kafka/pull/1068 KAFKA-3397: add missing 'REQUIRED' for tools.GetOffsetShell minor fix, or we will get a error message: >Missing required argument "[time]" You can merge this pull request into a Git repository b

[jira] [Updated] (KAFKA-3013) Display the topic-partition in the exception message for expired batches in recordAccumulator

[ https://issues.apache.org/jira/browse/KAFKA-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gwen Shapira updated KAFKA-3013: Resolution: Fixed Fix Version/s: 0.10.0.0 Status: Resolved (was: Patch Available)

[jira] [Commented] (KAFKA-3013) Display the topic-partition in the exception message for expired batches in recordAccumulator

[ https://issues.apache.org/jira/browse/KAFKA-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194596#comment-15194596 ] ASF GitHub Bot commented on KAFKA-3013: --- 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

[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

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

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

[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] [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:

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

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

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

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

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

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

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

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

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

See

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

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

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

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

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

[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

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

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

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

[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

[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]: 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

[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

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

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

[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

[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

[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

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

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

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=15194134#comment-15194134 ] Grant Henke commented on KAFKA-3394: [~hachikuji] I agree that allowing nulls everywhe

[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

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=15194089#comment-15194089 ] Grant Henke commented on KAFKA-3394: This could happen for basically any string in the

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

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

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

[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

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

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

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

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

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

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

[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

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. >

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

[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

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

[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

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

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

  1   2   >