Re: [DISCUSS] KIP-71 Enable log compaction and deletion to co-exist

Thanks for the proposal. I'm +1 overall with a thought somewhat related to Jun's comments. While there may not yet be a sensible use case for it, it should be (in theory) legal to have compact_and_delete with size based retention as well. I'm just wondering if it makes sense to allow specifying mu

Stream processing meetup at LinkedIn (Mountain View) on Tuesday, August 23 at 6pm

Hi everyone, We would like to invite you to a Stream Processing Meetup at LinkedIn’s *Mountain View campus on Tuesday, August 23 at 6pm*. Please RSVP here (only if you intend to attend in person): https://www.meetup.com/Stream-Processing-Meetup-LinkedIn/events/232864129 We have three great talks

Re: [DISCUSS] KIP-73: Replication Quotas

gt; When there are several unthrottled replicas, we could also just do > > what's > > > > suggested in KIP-74. The client is responsible for reordering the > > > > partitions and the leader fills in the bytes to those partitions in > > > order, &

Re: [DISCUSS] Time-based releases for Apache Kafka

On Wed, Aug 10, 2016 at 5:44 PM, Joel Koshy wrote: > > > On Tue, Aug 9, 2016 at 4:49 PM, Gwen Shapira wrote: > >> >> 4. Frequent releases mean we need to do bugfix releases for older >> branches. Right now we only do bugfix releases to latest release. >> &g

Re: [DISCUSS] Time-based releases for Apache Kafka

On Tue, Aug 9, 2016 at 4:49 PM, Gwen Shapira wrote: > > 4. Frequent releases mean we need to do bugfix releases for older > branches. Right now we only do bugfix releases to latest release. > I'm a bit unclear on how the above is a side-effect of time-based releases. IIUC this just changes how f

Re: Consumer Offset Migration Tool

There is an old jira on getting the old import/export ZK offsets tool to work for Kafka-based offsets . Ideally, that should be done in the kafka-consumer-groups tool. We could have kafka-consumer-groups tool support import/export for ZK-based offse

Re: [DISCUSS] KIP-73: Replication Quotas

with an example how this would be handled : > > *guaranteeing > > ordering of updates when replicas shift threads* > > > > Thanks, > > > > Mayuresh > > > > > > On Tue, Aug 9, 2016 at 10:49 AM, Joel Koshy wrote: > > > > &g

Re: [DISCUSS] KIP-73: Replication Quotas

e issue with approach (1) is that it departs somewhat from the existing > > quotas implementation, and must include a notion of fairness within, the > > now size-bounded, request and response. The issue with (2) is > guaranteeing > > ordering of updates when replicas shift threads, but this

Re: [DISCUSS] KIP-73: Replication Quotas

Hi Ben, Thanks for the detailed write-up. So the proposal involves self-throttling on the fetcher side and throttling at the leader. Can you elaborate on the reasoning that is given on the wiki: *“The throttle is applied to both leaders and followers. This allows the admin to exert strong guarante

Re: [DISCUSS] KIP-72 Allow Sizing Incoming Request Queue in Bytes

> > . >> >> > Hi Becket, > > I don't think progress can be made in the processor's run loop if the > queue fills up. i.e., I think Jun's point is that if the queue is full > (either due to the proposed max.bytes or today due to max.requests hitting > the limit) then processCompletedReceives will bl

Re: [DISCUSS] KIP-72 Allow Sizing Incoming Request Queue in Bytes

> > > > 2. Good point about the consequence when the processor threads are > blocking. I agree it would be important to keep the processor thread > running, but I am not sure if it would be a problem of the current > proposal. In most of the time, the request queue should be close to empty, > so th

Re: [kafka-clients] [VOTE] 0.10.0.1 RC2

+1 (binding) Thanks Ismael! On Thu, Aug 4, 2016 at 6:54 AM, Ismael Juma wrote: > Hello Kafka users, developers and client-developers, > > This is the third candidate for the release of Apache Kafka 0.10.0.1. This > is a bug fix release and it includes fixes and improvements from 53 JIRAs > (inc

Kafka/Samza meetup at LinkedIn, June 15, 6pm

[bcc: us...@kafka.apache.org, dev@kafka.apache.org] Hi everyone, We would like to invite you to our first Stream Processing Meetup at LinkedIn on June 15 at 6pm. Please RSVP here: http://www.meetup.com/Stream-Processing-Meetup-LinkedIn/events/231454378 Going forward (at LinkedIn) we will host me

Re: [DISCUSS] scalability limits in the coordinator

> Yes it would be a protocol bump. > Sorry - I'm officially confused. I think it may not be required - since the more compact format would be associated with a new assignment strategy - right? > smaller than the plaintext PAL, but the post-compressed binary PAL is just > 25% smaller than the pos

Re: [DISCUSS] scalability limits in the coordinator

Yes it would be a protocol bump. @Jason - on reducing the size of the assignment field, I would be interested to see what savings we can get - but my hunch is that we would end up picking one of either: a compact assignment field format or turn on compression. We actually did a similar investigati

Re: [VOTE] KIP-58 - Make Log Compaction Point Configurable

+1 on the proposal Re: inconsistent names: KAFKA-3234 has a patch and discussion in the PR that should help address the inconsistencies and various other issues but we decided it would need a small KIP. (If someone else wishes to take over that fe

Re: [DISCUSS] mbeans overwritten with identical clients on a single jvm

Currently, the only available mechanism to disambiguate between producer/consumer clients in the same JVM is the client-id. However, that does not play very well with the current definition of client-id and its use as the entity for quota enforcement. i.e., an application can thwart quota enforceme

Re: [VOTE] KIP-33 - Add a time based log index

Hi Becket, +1 Just a few more minor comments that I don't think should result in any material change to the KIP: - Under "time index format": *A time index entry (timestamp, offset) means that any message whose timestamp is greater than timestamp come after offset. * - I think it may

[jira] [Commented] (KAFKA-3494) mbeans overwritten with identical clients on a single jvm

[ https://issues.apache.org/jira/browse/KAFKA-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228733#comment-15228733 ] Joel Koshy commented on KAFKA-3494: --- I'm not sure that the second suggested so

[jira] [Updated] (KAFKA-3234) Minor documentation edits: clarify minISR; some topic-level configs are missing

[ https://issues.apache.org/jira/browse/KAFKA-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy updated KAFKA-3234: -- Fix Version/s: (was: 0.10.0.0) 0.10.0.1 > Minor documentation edits: clar

Re: [VOTE] KIP-45: Standardize KafkaConsumer API to use Collection

+1 On Tue, Mar 15, 2016 at 2:18 PM, Jason Gustafson wrote: > I'd like to open the vote for KIP-45. We've discussed several alternatives > on the mailing list and in the KIP call, but this vote is only on the > documented KIP: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=613

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

@Gwen - yes it did come back to per-API versions - I think that happened toward the end of the KIP hangout. I already said this, but personally I'm also in favor of per-API versions. A global/aggregate API version also works but that is just a proxy to a vector of per-API versions and at the end of

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

[jira] [Updated] (KAFKA-2960) DelayedProduce may cause message loss during repeated leader change

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

[jira] [Resolved] (KAFKA-1148) Delayed fetch/producer requests should be satisfied on a leader change

[ https://issues.apache.org/jira/browse/KAFKA-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy resolved KAFKA-1148. --- Resolution: Fixed Fix Version/s: 0.10.0.0 Issue resolved by pull request 1018 [https

[jira] [Updated] (KAFKA-3197) Producer can send message out of order even when in flight request is set to 1.

[ https://issues.apache.org/jira/browse/KAFKA-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy updated KAFKA-3197: -- Resolution: Fixed Status: Resolved (was: Patch Available) Pushed to trunk. > Producer

Re: [VOTE] Release plan - Kafka 0.10.0

+1 On Mon, Mar 7, 2016 at 9:27 AM, Gwen Shapira wrote: > Greetings Kafka Developer Community, > > As you all know, we have few big features that are almost complete > (Timestamps! Interceptors! Streams!). It is time to start planning our > next release. > > I suggest the following: > * Cut branc

Re: [DISCUSS] KIP-49: Fair Partition Assignment Strategy

at use case, we would be > happy. Is there a Jira open for the "flaw" that you mentioned? > > > > > On 2/26/16, 7:22 PM, "Joel Koshy" wrote: > > >Hi Andrew, > > > >Thanks for the wiki. Just a couple of comments: > > > > - The

Re: [VOTE] Deprecating the old Scala producers for 0.10.0.0

+1 On Thu, Mar 3, 2016 at 2:36 PM, Ismael Juma wrote: > Hi all, > > The new Java producer was introduced in 0.8.2.0 (released in February > 2015). It has become the default implementation for various tools since > 0.9.0.0 (released in October 2015) and it is the only implementation with > suppor

Re: [DISCUSS] KIP-49: Fair Partition Assignment Strategy

Hi Andrew, Thanks for the wiki. Just a couple of comments: - The disruptive config change issue that you mentioned is pretty much a non-issue in the new consumer due to central assignment. - Optional: but it may be helpful to add a concrete example. - More of an orthogonal observation

Re: Upgrading to Kafka 0.9.x

The 0.9 release still has the old consumer as Jay mentioned but this specific release is a little unusual in that it also provides a completely new consumer client. Based on what I understand, users of Kafka need to upgrade their brokers to > Kafka 0.9.x first, before they upgrade their clients to

[jira] [Resolved] (KAFKA-3298) Document unclean.leader.election.enable as a valid topic-level config

[ https://issues.apache.org/jira/browse/KAFKA-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy resolved KAFKA-3298. --- Resolution: Duplicate Thanks for the report. KAFKA-3234 addresses this and other such inconsistencies

[jira] [Commented] (KAFKA-3197) Producer can send message out of order even when in flight request is set to 1.

[ https://issues.apache.org/jira/browse/KAFKA-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15168065#comment-15168065 ] Joel Koshy commented on KAFKA-3197: --- Hi [~fpj] so your suggestion is to preempti

Re: [DISCUSS] KIP-47 - Add timestamp-based log deletion policy

it deems fit. It doesn't need to compute any fuzzy > windows, try to wait until asynchronous processes have been completed or > continually flip settings between enabled and disabled. > > I will update the KIP to reflect the discussion around LogAppendTime vs > CreateTime and

Re: [DISCUSS] KIP-47 - Add timestamp-based log deletion policy

I'm having some trouble reconciling the current proposal with your original requirement which was essentially being able to purge log data up to a precise point (an offset). The KIP currently suggests that timestamp-based deletion would only work with LogAppendTime, so it does not seem significantl

Re: [DISCUSS] Deprecating the old Scala producers for the next release

+1 Thanks for bringing it up On Mon, Feb 22, 2016 at 9:36 AM, Ismael Juma wrote: > Hi all, > > The new Java producer was introduced in 0.8.2.0 (released in February > 2015). It has become the default implementation for various tools since > 0.9.0.0 (released in October 2015) and it is the only

Re: request to become contributor

Done - and I left a comment on that ticket as well. On Thu, Feb 18, 2016 at 11:32 AM, Dustin Cote wrote: > Hi folks, > > I wanted to take a crack at implementing KAFKA-2670 > . I think it's a fairly > straightforward implementation. Can I be ad

[jira] [Commented] (KAFKA-2670) add sampling rate to MirrorMaker

[ https://issues.apache.org/jira/browse/KAFKA-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153180#comment-15153180 ] Joel Koshy commented on KAFKA-2670: --- It should be possible to accomplish this wi

Re: [kafka-clients] 0.9.0.1 RC1

+1 On Thu, Feb 11, 2016 at 6:55 PM, Jun Rao wrote: > This is the first candidate for release of Apache Kafka 0.9.0.1. This a > bug fix release that fixes 70 issues. > > Release Notes for the 0.9.0.1 release > https://home.apache.org/~junrao/kafka-0.9.0.1-candidate1/RELEASE_NOTES.html > > *** Ple

[jira] [Closed] (KAFKA-3088) 0.9.0.0 broker crash on receipt of produce request with empty client ID

[ https://issues.apache.org/jira/browse/KAFKA-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy closed KAFKA-3088. - Thanks for the patches - this has been pushed to trunk and 0.9 > 0.9.0.0 broker crash on receipt of prod

[jira] [Commented] (KAFKA-3088) 0.9.0.0 broker crash on receipt of produce request with empty client ID

[ https://issues.apache.org/jira/browse/KAFKA-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15145738#comment-15145738 ] Joel Koshy commented on KAFKA-3088: --- [~granthenke] I'm leaving this open for

Re: [DISCUSS] KIP-36 - Rack aware replica assignment

We are adding a NULLABLE_STRING type (KAFKA-3088) but you would then need to evolve the UpdateMetadata request. Regardless, it seems better to just go with an empty string. On Fri, Feb 12, 2016 at 5:38 PM, Allen Wang wrote: > In implementing changes to UpdateMetadataRequest, I noticed > that org

[jira] [Created] (KAFKA-3234) Minor documentation edits: clarify minISR; some topic-level configs are missing

Joel Koshy created KAFKA-3234: - Summary: Minor documentation edits: clarify minISR; some topic-level configs are missing Key: KAFKA-3234 URL: https://issues.apache.org/jira/browse/KAFKA-3234 Project

[jira] [Commented] (KAFKA-2750) Sender.java: handleProduceResponse does not check protocol version

[ https://issues.apache.org/jira/browse/KAFKA-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140105#comment-15140105 ] Joel Koshy commented on KAFKA-2750: --- [~felixgv] You mean retry with the older prot

[jira] [Updated] (KAFKA-3179) Kafka consumer delivers message whose offset is earlier than sought offset.

[ https://issues.apache.org/jira/browse/KAFKA-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy updated KAFKA-3179: -- Resolution: Fixed Fix Version/s: (was: 0.9.0.1) 0.9.1.0 Status

[jira] [Commented] (KAFKA-3197) Producer can send message out of order even when in flight request is set to 1.

[ https://issues.apache.org/jira/browse/KAFKA-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130785#comment-15130785 ] Joel Koshy commented on KAFKA-3197: --- Sorry - hit enter too soon. "in that it

[jira] [Commented] (KAFKA-3197) Producer can send message out of order even when in flight request is set to 1.

[ https://issues.apache.org/jira/browse/KAFKA-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130781#comment-15130781 ] Joel Koshy commented on KAFKA-3197: --- [~enothereska] - the documentation is accurat

Re: [VOTE] KIP-42 -- Add Producer and Consumer Interceptors.

+1 On Monday, February 1, 2016, Anna Povzner wrote: > Hi All, > > I am opening the voting thread for KIP-42: Add Producer and Consumer > Interceptors. > > For reference, here's the KIP wiki: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-42%3A+Add+Producer+and+Consumer+Interceptors >

Re: [DISCUSS] KIP-42: Add Producer and Consumer Interceptors

Responding to some of the earlier comments in the thread: @Jay/@Neha, I think any one of onCommit/onAppend/onArrival would work for the concrete use-case that I had outlined. I think onArrival is additionally useful for custom validation - i.e., reject the message and do not append if it violates

Re: [DISCUSS] KIP-42: Add Producer and Consumer Interceptors

I'm definitely in favor of having such hooks in the produce/consume life-cycle. Not sure if people remember this but in Kafka 0.7 this was pretty much how it was: https://github.com/apache/kafka/blob/0.7/core/src/main/scala/kafka/producer/async/CallbackHandler.scala i.e., we had something similar t

[jira] [Commented] (KAFKA-3088) 0.9.0.0 broker crash on receipt of produce request with empty client ID

[ https://issues.apache.org/jira/browse/KAFKA-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15111679#comment-15111679 ] Joel Koshy commented on KAFKA-3088: --- [~aauradkar] can chime in since this is relate

[jira] [Commented] (KAFKA-2758) Improve Offset Commit Behavior

[ https://issues.apache.org/jira/browse/KAFKA-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15111675#comment-15111675 ] Joel Koshy commented on KAFKA-2758: --- Unless I'm misunderstanding I don&#

[jira] [Created] (KAFKA-3124) Update protocol wiki page to reflect latest request/response formats

Joel Koshy created KAFKA-3124: - Summary: Update protocol wiki page to reflect latest request/response formats Key: KAFKA-3124 URL: https://issues.apache.org/jira/browse/KAFKA-3124 Project: Kafka

Re: [VOTE] KIP-36 - Rack aware replica assignment

+1 (binding) On Tue, Jan 19, 2016 at 10:31 AM, Aditya Auradkar < aaurad...@linkedin.com.invalid> wrote: > +1 (non-binding) > > On Tue, Jan 19, 2016 at 8:28 AM, Grant Henke wrote: > > > +1 (non-binding) > > > > On Tue, Jan 19, 2016 at 7:46 AM, Ismael Juma wrote: > > > > > +1 (non-binding) > > >

Re: [VOTE] KIP-41: Consumer Max Records

+1 On Wed, Jan 13, 2016 at 3:18 PM, Jason Gustafson wrote: > Hi All, > > I'd like to open up the vote on KIP-41. This KIP adds a new consumer > configuration option "max.poll.records" which sets an upper bound on the > number of records returned in a call to poll(). This gives users a way to > l

Re: [VOTE] KIP-32 Add CreateTime and LogAppendTime to Kafka message.

r to implement > this as part of KIP-32, rather than proposing a new KIP. > > Thanks, > Anna > > > On Fri, Jan 8, 2016 at 12:53 PM, Joel Koshy wrote: > > > +1 from me > > > > Looking through this thread it seems there was some confusion on the > > migratio

Re: [VOTE] KIP-32 Add CreateTime and LogAppendTime to Kafka message.

+1 from me Looking through this thread it seems there was some confusion on the migration discussion. This discussion in fact happened in the KIP-31 discuss thread, not so much in the KIP hangout. There is considerable overlap in discussions between KIP-3[1,2,3] so it makes sense to cross-referenc

Re: [DISCUSS] KIP-30 Allow for brokers to have plug-able consensus and meta data storage sub systems

I’m on an extended vacation but "a native consensus implementation in Kafka" is one of my favorite topics so I’m compelled to chime in :) I have actually been thinking along the same lines that Jay is saying after reading the Raft paper - a couple of us at LinkedIn have had casual discussions about

[jira] [Created] (KAFKA-2863) Authorizer should provide lifecycle (shutdown) methods

Joel Koshy created KAFKA-2863: - Summary: Authorizer should provide lifecycle (shutdown) methods Key: KAFKA-2863 URL: https://issues.apache.org/jira/browse/KAFKA-2863 Project: Kafka Issue Type

[jira] [Resolved] (KAFKA-2664) Adding a new metric with several pre-existing metrics is very expensive

[ https://issues.apache.org/jira/browse/KAFKA-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy resolved KAFKA-2664. --- Resolution: Fixed Fix Version/s: (was: 0.9.0.1) 0.9.0.0 Issue resolved

[jira] [Resolved] (KAFKA-2663) Add quota-delay time to request processing time break-up

[ https://issues.apache.org/jira/browse/KAFKA-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy resolved KAFKA-2663. --- Resolution: Fixed Fix Version/s: (was: 0.9.0.1) 0.9.0.0 Issue resolved

[jira] [Commented] (KAFKA-2235) LogCleaner offset map overflow

[ https://issues.apache.org/jira/browse/KAFKA-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974502#comment-14974502 ] Joel Koshy commented on KAFKA-2235: --- Agreed with Todd - this is very similar to

[jira] [Commented] (KAFKA-2235) LogCleaner offset map overflow

[ https://issues.apache.org/jira/browse/KAFKA-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14971728#comment-14971728 ] Joel Koshy commented on KAFKA-2235: --- While I think the change is well-motivated I&#

Re: [VOTE] KIP-38: ZooKeeper authentication

+1 binding On Wed, Oct 21, 2015 at 8:17 AM, Flavio Junqueira wrote: > Thanks everyone for the feedback so far. At this point, I'd like to start > a vote for KIP-38. > > Summary: Add support for ZooKeeper authentication > KIP page: > https://cwiki.apache.org/confluence/display/KAFKA/KIP-38%3A+Zoo

[jira] [Updated] (KAFKA-2454) Dead lock between delete log segment and shutting down.

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

Re: [DISCUSS] KIP-32 - Add CreateTime and LogAppendTime to Kafka message

I’m in favor of adding the create-time in the message (although some would argue even that should really be an application-level header), but I don’t think it should be mutable after it leaves the client and I think we should avoid having the server use that for any server-side indexing. The max.a

[jira] [Created] (KAFKA-2668) Add a metric that records the total number of metrics

Joel Koshy created KAFKA-2668: - Summary: Add a metric that records the total number of metrics Key: KAFKA-2668 URL: https://issues.apache.org/jira/browse/KAFKA-2668 Project: Kafka Issue Type

[jira] [Commented] (KAFKA-2664) Adding a new metric with several pre-existing metrics is very expensive

[ https://issues.apache.org/jira/browse/KAFKA-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961595#comment-14961595 ] Joel Koshy commented on KAFKA-2664: --- [~gwenshap] in general yes it could, but i

[jira] [Created] (KAFKA-2664) Adding a new metric with several pre-existing metrics is very expensive

Joel Koshy created KAFKA-2664: - Summary: Adding a new metric with several pre-existing metrics is very expensive Key: KAFKA-2664 URL: https://issues.apache.org/jira/browse/KAFKA-2664 Project: Kafka

[jira] [Created] (KAFKA-2663) Add quota-delay time to request processing time break-up

Joel Koshy created KAFKA-2663: - Summary: Add quota-delay time to request processing time break-up Key: KAFKA-2663 URL: https://issues.apache.org/jira/browse/KAFKA-2663 Project: Kafka Issue Type

[jira] [Updated] (KAFKA-2660) Correct cleanableRatio calculation

[ https://issues.apache.org/jira/browse/KAFKA-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy updated KAFKA-2660: -- Reviewer: Joel Koshy > Correct cleanableRatio calculat

[jira] [Commented] (KAFKA-2017) Persist Coordinator State for Coordinator Failover

[ https://issues.apache.org/jira/browse/KAFKA-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959392#comment-14959392 ] Joel Koshy commented on KAFKA-2017: --- btw, I just realized a migration as descr

[jira] [Commented] (KAFKA-2017) Persist Coordinator State for Coordinator Failover

[ https://issues.apache.org/jira/browse/KAFKA-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959266#comment-14959266 ] Joel Koshy commented on KAFKA-2017: --- bq. But if we really want to have group meta

[jira] [Commented] (KAFKA-2017) Persist Coordinator State for Coordinator Failover

[ https://issues.apache.org/jira/browse/KAFKA-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14958442#comment-14958442 ] Joel Koshy commented on KAFKA-2017: --- Ashish, that is correct - consumers can s

[jira] [Commented] (KAFKA-2017) Persist Coordinator State for Coordinator Failover

[ https://issues.apache.org/jira/browse/KAFKA-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14957348#comment-14957348 ] Joel Koshy commented on KAFKA-2017: --- If we reused this topic, then I think we could

[jira] [Commented] (KAFKA-2017) Persist Coordinator State for Coordinator Failover

[ https://issues.apache.org/jira/browse/KAFKA-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14957204#comment-14957204 ] Joel Koshy commented on KAFKA-2017: --- I agree with those benefits. If we go that r

[jira] [Commented] (KAFKA-2017) Persist Coordinator State for Coordinator Failover

[ https://issues.apache.org/jira/browse/KAFKA-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14956108#comment-14956108 ] Joel Koshy commented on KAFKA-2017: --- In offline threads we were going to discuss

[jira] [Resolved] (KAFKA-2567) throttle-time shouldn't be NaN

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

[jira] [Resolved] (KAFKA-2443) Expose windowSize on Rate

[ https://issues.apache.org/jira/browse/KAFKA-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy resolved KAFKA-2443. --- Resolution: Fixed Fix Version/s: 0.9.0.0 Issue resolved by pull request 213 [https

Re: Review Request 33049: Patch for KAFKA-2084

dering if it should be documented otherwise others who try to derive it from first principles may scratch their heads as I did. - Joel Koshy On Aug. 15, 2015, 12:43 a.m., Aditya Auradkar wrote: > > --- > This is an automatically g

[jira] [Resolved] (KAFKA-2419) Allow certain Sensors to be garbage collected after inactivity

[ https://issues.apache.org/jira/browse/KAFKA-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy resolved KAFKA-2419. --- Resolution: Fixed > Allow certain Sensors to be garbage collected after inactiv

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

Thanks for the write-up and discussion. This would have been super useful in our last round of deployments at LinkedIn for which we ended up having to hack around a number of incompatibilities. I could list all of the compatibility issues that have hit us, but some are irrelevant to this specific K

Re: Review Request 36858: Patch for KAFKA-2120

/KafkaConsumer.java (line 427) <https://reviews.apache.org/r/36858/#comment158946> Yeah I don't quite see why it needs more work - Mayuresh - can you comment? - Joel Koshy On Sept. 28, 2015, 11:16 p.m., Mayuresh Gharat wrote: > >

Re: Review Request 36858: Patch for KAFKA-2120

/KafkaConsumer.java (line 427) <https://reviews.apache.org/r/36858/#comment158944> LGTM - Guozhang, can you do a trivial commit to remove it? (Or I can do it later today/tomorrow) - Joel Koshy On Sept. 28, 2015, 11:16 p.m., Mayuresh Gharat

[jira] [Commented] (KAFKA-2580) Kafka Broker keeps file handles open for all log files (even if its not written to/read from)

[ https://issues.apache.org/jira/browse/KAFKA-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943698#comment-14943698 ] Joel Koshy commented on KAFKA-2580: --- I was wondering if we can do with something

[jira] [Commented] (KAFKA-2584) SecurityProtocol enum validation should be removed or relaxed for non-config usages

[ https://issues.apache.org/jira/browse/KAFKA-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943694#comment-14943694 ] Joel Koshy commented on KAFKA-2584: --- Here is a quick summary of the patch we ende

Re: [DISCUSS] KIP-31 - Message format change proposal

Please let me know if you have concern about the updated proposal. > > Thanks, > > Jiangjie (Becket) Qin > > On Fri, Sep 25, 2015 at 11:26 AM, Joel Koshy wrote: > >> Hey Becket, >> >> I do think we need the interim deployment phase, set >> message.forma

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

[ https://issues.apache.org/jira/browse/KAFKA-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy updated KAFKA-2120: -- Resolution: Fixed Status: Resolved (was: Patch Available) +1 and committed to trunk. > Ad

Re: Review Request 36858: Patch for KAFKA-2120

ads to initialization issues - you can verify this by enabling logs in the unit test for `LogRecoveryTest`. You can address this by explicitly setting `RequestTimeoutMs` and then `val ControllerSocketTimeoutMs = RequestTimeoutMs`. - Joel Koshy On Sept. 19, 2015, 2:27 a.m., Mayuresh Gharat

[jira] [Commented] (KAFKA-2580) Kafka Broker keeps file handles open for all log files (even if its not written to/read from)

[ https://issues.apache.org/jira/browse/KAFKA-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933781#comment-14933781 ] Joel Koshy commented on KAFKA-2580: --- [~guozhang] actually it is now at

[jira] [Created] (KAFKA-2584) SecurityProtocol enum validation should be removed or relaxed for non-config usages

Joel Koshy created KAFKA-2584: - Summary: SecurityProtocol enum validation should be removed or relaxed for non-config usages Key: KAFKA-2584 URL: https://issues.apache.org/jira/browse/KAFKA-2584 Project

Re: [DISCUSS] KIP-31 - Message format change proposal

ot from some other messages. Would > that be a problem? > > If (A) and (B) are not a problem. Is the above procedure able to address > your concern? > > Thanks, > > Jiangjie (Becket) Qin > > On Thu, Sep 24, 2015 at 6:32 PM, Joel Koshy wrote: > >> The upgrade

Re: [DISCUSS] KIP-31 - Message format change proposal

he TopicPartitionKeySegment key in the timestamp index >> map. >> > > >> 2. delete the timestamp index file >> > > >> >> > > >> This solution assumes we only keep CreateTime in the message. There >> > are >> >

Re: [VOTE] KIP-31 - Move to relative offsets in compressed message sets.

+1 on everything but the upgrade plan, which is a bit scary - will comment on the discuss thread. On Thu, Sep 24, 2015 at 9:51 AM, Mayuresh Gharat wrote: > +1 > > On Wed, Sep 23, 2015 at 10:16 PM, Guozhang Wang wrote: > >> ＋1 >> >> On Wed, Sep 23, 2015 at 9:32 PM, Aditya Auradkar < >> aaurad...@

[jira] [Comment Edited] (KAFKA-1911) Log deletion on stopping replicas should be async

[ https://issues.apache.org/jira/browse/KAFKA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14903046#comment-14903046 ] Joel Koshy edited comment on KAFKA-1911 at 9/22/15 5:3

[jira] [Commented] (KAFKA-1911) Log deletion on stopping replicas should be async

[ https://issues.apache.org/jira/browse/KAFKA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14903046#comment-14903046 ] Joel Koshy commented on KAFKA-1911: --- The original motivation in this ticket wa

Re: [ANNOUNCE] New Committer Sriharsha Chintalapani

Congrats Sriharsha! Joel On Tue, Sep 22, 2015 at 9:52 AM, Neha Narkhede wrote: > Congrats Sriharsha. Glad to have you on the team. > > On Tue, Sep 22, 2015 at 8:44 AM, wrote: > >> Congrats Sriharsha! >> >> Thanks, >> >> Mayuresh >> >> Sent from my iPhone >> >> > On Sep 22, 2015, at 8:27 AM, Jay

[jira] [Commented] (KAFKA-2438) add maxParallelForks to build.gradle to speedup tests

[ https://issues.apache.org/jira/browse/KAFKA-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14876545#comment-14876545 ] Joel Koshy commented on KAFKA-2438: --- FYI, I find that this patch appears to exacer

Re: Add To Contributor List

Done. Thanks, Joel On Fri, Sep 18, 2015 at 2:57 AM, Dheeraj Sharma wrote: > I already have a jira account: > > Username: dheerajsharma1990 > Name: Dheeraj Sharma > > But as mentioned in the http://kafka.apache.org/contributing.html page > "Please contact us to be added the contributor list.Afte

[jira] [Commented] (KAFKA-2419) Allow certain Sensors to be garbage collected after inactivity

[ https://issues.apache.org/jira/browse/KAFKA-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14875986#comment-14875986 ] Joel Koshy commented on KAFKA-2419: --- However, we should think through the effec

<    1   2   3   4   5   6   7   8   9   10   >