[
https://issues.apache.org/jira/browse/KAFKA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke resolved KAFKA-2124.
Resolution: Duplicate
Assignee: Grant Henke
> gradlew is not working on a fresh check
[
https://issues.apache.org/jira/browse/KAFKA-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke resolved KAFKA-4906.
Resolution: Won't Fix
> Support 0.9 brokers with a newer Producer or Consumer
[
https://issues.apache.org/jira/browse/KAFKA-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15927449#comment-15927449
]
Grant Henke commented on KAFKA-4906:
[~ijuma] Following up with a summary of som
[
https://issues.apache.org/jira/browse/KAFKA-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-4906:
---
Fix Version/s: (was: 0.10.2.1)
> Support 0.9 brokers with a newer Producer or Consumer vers
Grant Henke created KAFKA-4906:
--
Summary: Support 0.9 brokers with a newer Producer or Consumer
version
Key: KAFKA-4906
URL: https://issues.apache.org/jira/browse/KAFKA-4906
Project: Kafka
Colin
> > >
> >
> >
> >
> > --
> > *Gwen Shapira*
> > Product Manager | Confluent
> > 650.450.2760 | @gwenshap
> > Follow us: Twitter <https://twitter.com/ConfluentInc> | blog
> > <http://www.confluent.io/blog>
> >
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
+Add+Reset+Consumer+Group+Offsets+tooling
> >
> >
> > Thanks!
> >
> > Jorge.
> >
>
>
>
> --
> *Gwen Shapira*
> Product Manager | Confluent
> 650.450.2760 | @gwenshap
> Follow us: Twitter <https://twitter.com/ConfluentInc> | blog
> <http://www.confluent.io/blog>
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
Feel free to create a KIP based on that discussion and drive the jira. I
don't think a KIP exists yet.
On Thu, Mar 2, 2017 at 1:28 PM, Jeff Widman wrote:
> Thanks, that's the ticket I was thinking of.
>
> On Thu, Mar 2, 2017 at 11:19 AM, Grant Henke wrote:
>
> > I
7;t find anything in JIRA... am I imagining things?
>
> Now that there's API support for creating topics, the version bump to
> 0.11.0 seems like a good time to re-evaluate whether this default should be
> flipped to false.
>
> I'm happy to create a KIP if needed, just
gt; >
> > Thanks,
> > Ismael
> >
>
>
>
> --
> *Gwen Shapira*
> Product Manager | Confluent
> 650.450.2760 | @gwenshap
> Follow us: Twitter <https://twitter.com/ConfluentInc> | blog
> <http://www.confluent.io/blog>
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
[
https://issues.apache.org/jira/browse/KAFKA-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879124#comment-15879124
]
Grant Henke commented on KAFKA-2729:
I am curious if everyone on this Jir
[
https://issues.apache.org/jira/browse/KAFKA-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15872139#comment-15872139
]
Grant Henke commented on KAFKA-4754:
{quote}
This could expose the password to an
[
https://issues.apache.org/jira/browse/KAFKA-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15872127#comment-15872127
]
Grant Henke commented on KAFKA-4754:
{quote}
Hmm. It is not a good practice to
[
https://issues.apache.org/jira/browse/KAFKA-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-4754:
---
Status: Patch Available (was: Open)
> Correctly parse '=' characters in command l
[
https://issues.apache.org/jira/browse/KAFKA-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860597#comment-15860597
]
Grant Henke commented on KAFKA-4754:
Its worth noting, it was also possible to
Grant Henke created KAFKA-4754:
--
Summary: Correctly parse '=' characters in command line overrides
Key: KAFKA-4754
URL: https://issues.apache.org/jira/browse/KAFKA-4754
Project: Kafka
.11
> >
> >
> > The vote will run for a minimum of 72 hours.
> >
> > Thanks,
> > Ismael
> >
> >
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
[
https://issues.apache.org/jira/browse/KAFKA-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858709#comment-15858709
]
Grant Henke commented on KAFKA-4746:
I just mean that often when working wi
Grant Henke created KAFKA-4746:
--
Summary: Offsets can be committed for the offsets topic
Key: KAFKA-4746
URL: https://issues.apache.org/jira/browse/KAFKA-4746
Project: Kafka
Issue Type: Bug
gt; change
> > it
> > >> to
> > >> > SCRAM?
> > >> >
> > >> >
> > >> Updated the diagram.
> > >>
> > >>
> > >>
> > >> Thanks,
> > >> Manikumar
> > >>
> > >>
> > >&
t;> good reason to go multi-process or consider storing more things off
> >> the
> >>>>>> Java heap.
> >>>>>>
> >>>>>
> >>>>> I see. Now I agree one-broker-per-disk should be more efficient in
> >> te
ent.
> >
> > Thanks for the comments, Becket!
> >
> > I agree that topic configuration change should be in the administrative
> > client. I have not thought about partition movement or preferred leader
> > election. It probably makes sense to put them in the cli
han based
> on
> > > who
> > > >> produced the data, and so it makes sense to me that the durability
> > > should
> > > >> be on the entire topic, not by the producer.
> > > >>
> > > >> What is a use case where you have multiple producers writing to the
> > same
> > > >> topic but would want different durability?
> > > >>
> > > >> -James
> > > >>
> > > >>> The ability to make this tradeoff in different places can seem more
> > > >> complex
> > > >>> (and really by definition *is* more complex), but it also offers
> more
> > > >>> flexibility.
> > > >>>
> > > >>> -Ewen
> > > >>>
> > > >>>
> > > >>>> But I understand your point, min.insync.replicas setting should be
> > > >>>> understood as "if a producer wants to get an error when topics are
> > > under
> > > >>>> replicated, then how many replicas are enough for not raising an
> > > error?"
> > > >>>>
> > > >>>>
> > > >>>> On Thu, Jan 26, 2017 at 4:16 PM, Ewen Cheslack-Postava <
> > > >> e...@confluent.io>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> The acks setting for the producer doesn't affect the final
> > durability
> > > >>>>> guarantees. These are still enforced by the replication and min
> ISR
> > > >>>>> settings. Instead, the ack setting just lets the producer control
> > how
> > > >>>>> durable the write is before *that producer* can consider the
> write
> > > >>>>> "complete", i.e. before it gets an ack.
> > > >>>>>
> > > >>>>> -Ewen
> > > >>>>>
> > > >>>>> On Tue, Jan 24, 2017 at 12:46 PM, Luciano Afranllie <
> > > >>>>> listas.luaf...@gmail.com> wrote:
> > > >>>>>
> > > >>>>>> Hi everybody
> > > >>>>>>
> > > >>>>>> I am trying to understand why Kafka let each individual
> producer,
> > > on a
> > > >>>>>> connection per connection basis, choose the tradeoff between
> > > >>>> availability
> > > >>>>>> and durability, honoring min.insync.replicas value only if
> > producer
> > > >>>> uses
> > > >>>>>> ack=all.
> > > >>>>>>
> > > >>>>>> I mean, for a single topic, cluster administrators can't enforce
> > > >>>> messages
> > > >>>>>> to be stores in a minimum number of replicas without
> coordinating
> > > with
> > > >>>>> all
> > > >>>>>> producers to that topic so all of them use ack=all.
> > > >>>>>>
> > > >>>>>> Is there something that I am missing? Is there any other
> strategy
> > to
> > > >>>>>> overcome this situation?
> > > >>>>>>
> > > >>>>>> Regards
> > > >>>>>> Luciano
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>
> > > >>
> > >
> > >
> >
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
/confluence/display/KAFKA/KIP-
> 119%3A+Drop+Support+for+Scala+2.10+in+Kafka+0.11
>
> Please take a look. Your feedback is appreciated.
>
> Thanks,
> Ismael
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
, but we know that it won't happen before
> > June 2017.
> >
> > Please take a look at the proposal and share your feedback.
> >
> > Thanks,
> > Ismael
> >
> > [1] http://search-hadoop.com/m/Kafka/uyzND1oIhV61GS5Sf2
> >
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
a process can't abort them, because the hang is in the kernel.
> It
> > >> is
> > >>>> not fun when threads are stuck in "D state"
> > >>>> http://stackoverflow.com/questions/20423521/process-perminan
> > >>>> tly-stuck-on-d-state
> > >>>> . Even kill -9 cannot abort the thread then. Fortunately, this is
> > >>>> rare.
> > >>>>
> > >>>
> > >>> I agree it is a harder problem and it is rare. We probably don't have
> > to
> > >>> worry about it in this KIP since this issue is orthogonal to whether
> or
> > >> not
> > >>> we use JBOD.
> > >>>
> > >>>
> > >>>>
> > >>>> Another approach we should consider is for Kafka to implement its
> own
> > >>>> storage layer that would stripe across multiple disks. This
> wouldn't
> > >>>> have to be done at the block level, but could be done at the file
> > >> level.
> > >>>> We could use consistent hashing to determine which disks a file
> should
> > >>>> end up on, for example.
> > >>>>
> > >>>
> > >>> Are you suggesting that we should distribute log, or log segment,
> > across
> > >>> disks of brokers? I am not sure if I fully understand this approach.
> My
> > >> gut
> > >>> feel is that this would be a drastic solution that would require
> > >>> non-trivial design. While this may be useful to Kafka, I would prefer
> > not
> > >>> to discuss this in detail in this thread unless you believe it is
> > >> strictly
> > >>> superior to the design in this KIP in terms of solving our use-case.
> > >>>
> > >>>
> > >>>> best,
> > >>>> Colin
> > >>>>
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Dong
> > >>>>>
> > >>>>> On Wed, Jan 25, 2017 at 11:34 AM, Colin McCabe >
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Hi Dong,
> > >>>>>>
> > >>>>>> Thanks for the writeup! It's very interesting.
> > >>>>>>
> > >>>>>> I apologize in advance if this has been discussed somewhere else.
> > >>> But
> > >>>> I
> > >>>>>> am curious if you have considered the solution of running multiple
> > >>>>>> brokers per node. Clearly there is a memory overhead with this
> > >>>> solution
> > >>>>>> because of the fixed cost of starting multiple JVMs. However,
> > >>> running
> > >>>>>> multiple JVMs would help avoid scalability bottlenecks. You could
> > >>>>>> probably push more RPCs per second, for example. A garbage
> > >>> collection
> > >>>>>> in one broker would not affect the others. It would be
> interesting
> > >>> to
> > >>>>>> see this considered in the "alternate designs" design, even if you
> > >>> end
> > >>>>>> up deciding it's not the way to go.
> > >>>>>>
> > >>>>>> best,
> > >>>>>> Colin
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Jan 12, 2017, at 10:46, Dong Lin wrote:
> > >>>>>>> Hi all,
> > >>>>>>>
> > >>>>>>> We created KIP-112: Handle disk failure for JBOD. Please find the
> > >>> KIP
> > >>>>>>> wiki
> > >>>>>>> in the link https://cwiki.apache.org/confl
> > >> uence/display/KAFKA/KIP-
> > >>>>>>> 112%3A+Handle+disk+failure+for+JBOD.
> > >>>>>>>
> > >>>>>>> This KIP is related to KIP-113
> > >>>>>>> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > >>>>>> 113%3A+Support+replicas+movement+between+log+directories>:
> > >>>>>>> Support replicas movement between log directories. They are
> > >> needed
> > >>> in
> > >>>>>>> order
> > >>>>>>> to support JBOD in Kafka. Please help review the KIP. You
> > >> feedback
> > >>> is
> > >>>>>>> appreciated!
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> Dong
> > >>>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
c no topics, but supports
> > > topic
> > > >>>> auto-creation as soon as a message is published to the topic
> > > >>>> 2) consumer subscribes using topic string or a regex pattern.
> > > Currently
> > > >> no
> > > >&
1, 2017 at 2:51 PM, Gwen Shapira wrote:
> >
> > > The PMC for Apache Kafka has invited Grant Henke to join as a
> > > committer and we are pleased to announce that he has accepted!
> > >
> > > Grant contributed 88 patches, 90 code reviews, countless great
Log Compaction Point Configurable (blocked - by KIP-33)
> >> - KIP-61: Add a log retention parameter for maximum disk space usage
> >>percentage (dormant)
> >> - KIP-68 Add a consumed log retention before log retention (dormant)
> >
> >
> >
Grant Henke created KAFKA-4525:
--
Summary: Kafka should not require SSL trust store password
Key: KAFKA-4525
URL: https://issues.apache.org/jira/browse/KAFKA-4525
Project: Kafka
Issue Type: Bug
[
https://issues.apache.org/jira/browse/KAFKA-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke resolved KAFKA-2552.
Resolution: Duplicate
> Certain admin commands such as partition assignment fail on large clust
Grant Henke created KAFKA-4203:
--
Summary: Java producer default max message size does not align
with broker default
Key: KAFKA-4203
URL: https://issues.apache.org/jira/browse/KAFKA-4203
Project: Kafka
Grant Henke created KAFKA-4157:
--
Summary: Transient system test failure in
replica_verification_test.test_replica_lags
Key: KAFKA-4157
URL: https://issues.apache.org/jira/browse/KAFKA-4157
Project
[
https://issues.apache.org/jira/browse/KAFKA-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-4157:
---
Status: Patch Available (was: Open)
> Transient system test failure
the discuss thread, making it not as visible as required. It's
> important
> > to
> > > mention that two +1s were cast by Gwen and Sriram:
> > >
> > > http://mail-archives.apache.org/mod_mbox/kafka-dev/201609.
> > mbox/%3CCAD5tkZbLv7fvH4q%2BKe%2B%3DJMgGq%2BZT2t34e0WRUsCT1ErhtKOg1w%
> > 40mail.gmail.com%3E
> >
>
>
>
> --
> Regards,
>
> Rajini
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
> priv...@kafka.apache.org >
> > >>>>>>>> Date: 09/06/2016 03:26 PM
> > >>>>>>>> Subject:[ANNOUNCE] New committer: Jason Gustafson
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> The PMC for Apache Kafka has invited Jason Gustafson to join
> > >> as a
> > >>>>>>>> committer and
> > >>>>>>>> we are pleased to announce that he has accepted!
> > >>>>>>>>
> > >>>>>>>> Jason has contributed numerous patches to a wide range of
> > >> areas,
> > >>>>>> notably
> > >>>>>>>> within the new consumer and the Kafka Connect layers. He has
> > >>>>> displayed
> > >>>>>>>> great taste and judgement which has been apparent through his
> > >>>>>> involvement
> > >>>>>>>> across the board from mailing lists, JIRA, code reviews to
> > >>>>> contributing
> > >>>>>>>> features, bug fixes and code and documentation improvements.
> > >>>>>>>>
> > >>>>>>>> Thank you for your contribution and welcome to Apache Kafka,
> > >>> Jason!
> > >>>>>>>> --
> > >>>>>>>> Thanks,
> > >>>>>>>> Neha
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> Ashish 🎤h
> > >>>
> > >>
> > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Rajini
> >
> >
>
>
> --
> -Regards,
> Mayuresh R. Gharat
> (862) 250-7125
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
ration time, but it seems questionable
> > > > whether
> > > > > > we
> > > > > > >> > need
> > > > > > >> > > this going forward (the new consumer doesn't even expose
> it
> > at
> > > > the
> > > > > > >> > moment).
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> > The KIP in its current form isn't adding a callback. So
> you'd
> > > > still
> > > > > > >> need to
> > > > > > >> > scan the cache and remove any expired offsets, however you
> > > > wouldn't
> > > > > > send
> > > > > > >> > the tombstone messages.
> > > > > > >> > Having a callback sounds useful, though it isn't clear to me
> > how
> > > > you
> > > > > > >> would
> > > > > > >> > know which offsets to remove from the cache on segment
> > > deletion? I
> > > > > > will
> > > > > > >> > look into it.
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > > 2. This KIP could also be useful for expiration in the
> case
> > > of a
> > > > > > cache
> > > > > > >> > > maintained on the client, but I don't see an obvious way
> > that
> > > > we'd
> > > > > > be
> > > > > > >> > able
> > > > > > >> > > to leverage it since there's no indication to the client
> > when
> > > a
> > > > > > >> segment
> > > > > > >> > has
> > > > > > >> > > been deleted (unless they reload the cache from the
> > beginning
> > > of
> > > > > the
> > > > > > >> > log).
> > > > > > >> > > One approach I can think of would be to write
> corresponding
> > > > > > >> tombstones as
> > > > > > >> > > necessary when a segment is removed, but that seems pretty
> > > > heavy.
> > > > > > Have
> > > > > > >> > you
> > > > > > >> > > considered this problem?
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > We've not considered this and I'm not sure we want to as
> part
> > of
> > > > > this
> > > > > > >> KIP.
> > > > > > >> >
> > > > > > >> > Thanks,
> > > > > > >> > Damian
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > On Mon, Aug 8, 2016 at 12:41 AM, Damian Guy <
> > > > damian@gmail.com
> > > > > >
> > > > > > >> > wrote:
> > > > > > >> > >
> > > > > > >> > > > Hi,
> > > > > > >> > > >
> > > > > > >> > > > We have created KIP 71: Enable log compaction and
> deletion
> > > to
> > > > > > >> co-exist`
> > > > > > >> > > >
> > > > > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > > > >> > > > 71%3A+Enable+log+compaction+and+deletion+to+co-exist
> > > > > > >> > > >
> > > > > > >> > > > Please take a look. Feedback is appreciated.
> > > > > > >> > > >
> > > > > > >> > > > Thank you
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
on before log retention (dormant)
Thank you,
Grant
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
rt modifying ACLs anyway (must use the
Ranger UI/API).
I wanted to explain my original thoughts, but I am happy to remove the
controller constraint given the SimpleAclAuthorizer appears to be the only
(of those I know) implementation to be affected.
Thank you,
Grant
On Sat, Aug 13, 2016
mmunity since she became a
> > Kafka committer
> > about a year ago. I am glad to announce that Gwen is now a member of
> Kafka
> > PMC.
> >
> > Congratulations, Gwen!
> >
> > Jun
> >
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
rokers
> in a Kafka cluster.
> > The code is available on GitHub at https://github.com/JThakrar/kafkaThe
> KIP page has the help documentation as well as the output from the command
> with various options.Thank you,Jayesh Thakrar
> >
> >
> >
>
>
>
> --
[
https://issues.apache.org/jira/browse/KAFKA-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-4032:
---
Status: Patch Available (was: Open)
> Uncaught exceptions when autocreating top
[
https://issues.apache.org/jira/browse/KAFKA-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-4038:
---
Status: Patch Available (was: Open)
> Transient failure
[
https://issues.apache.org/jira/browse/KAFKA-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke reassigned KAFKA-4038:
--
Assignee: Grant Henke
> Transient failure
[
https://issues.apache.org/jira/browse/KAFKA-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419992#comment-15419992
]
Grant Henke commented on KAFKA-3959:
[~onurkaraman] I understand the need for a q
[
https://issues.apache.org/jira/browse/KAFKA-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419471#comment-15419471
]
Grant Henke commented on KAFKA-3959:
I would like to present an alternative op
[
https://issues.apache.org/jira/browse/KAFKA-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419350#comment-15419350
]
Grant Henke commented on KAFKA-4032:
I will make a patch for this shortly
> U
[
https://issues.apache.org/jira/browse/KAFKA-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke reassigned KAFKA-4032:
--
Assignee: Grant Henke
> Uncaught exceptions when autocreating top
the
> consumer
> > group to be stopped before copying the offsets? Some applications may not
> > want to do that.
> >
> > Thanks,
> >
> > Jun
> >
> >
> > On Tue, Aug 9, 2016 at 10:01 AM, Grant Henke
> wrote:
> >
> >> I had to
in Apache Kafka? Any thoughts on the approach?
Thanks,
Grant
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
[
https://issues.apache.org/jira/browse/KAFKA-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-3934:
---
Summary: Start scripts enable GC by default with no way to disable (was:
kafka-server-start.sh
?
> >
> > The problem w/ being more descriptive is that its possible that
> > it restricts potential use cases if people think that somehow
> > their use case wouldn't fit.
> >
> >> 4. There is no CreateAcls or DeleteAcls (unlike CreateTopics an
(off 0.10.0 branch) is the 0.10.0.1-rc2 tag:
> >> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=tag;h=
> >> f8f56751744ba8e55f90f5c4f3aed8c3459447b2
> >> >
> >> > * Documentation:
> >> > http://kafka.apache.org/0100/documentation.
n the number of messages.
> >
> > This comes after several incidents at Linkedin where a sudden "spike" of
> > large message batches caused an out of memory exception.
> >
> > Thank you,
> >
> >Radai
> >
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
>> > >> some compatibility concerns.
> >> >
> >> > Isn't KIP-50 itself one gigantic compatibility concern? I don't see
> >> > how your suggestions make it any worse...
> >> >
> >>
> >> Yes, I also
[
https://issues.apache.org/jira/browse/KAFKA-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-2507:
---
Fix Version/s: 0.11.0.0
> Replace ControlledShutdown{Request,Response} w
[
https://issues.apache.org/jira/browse/KAFKA-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-3934:
---
Status: Patch Available (was: Open)
> kafka-server-start.sh enables GC by default with no way
Hi Parth,
Are you still working on this? If you need any help please don't hesitate
to ask.
Thanks,
Grant
On Thu, Jun 30, 2016 at 4:35 PM, Jun Rao wrote:
> Parth,
>
> Thanks for the reply.
>
> It makes sense to only allow the renewal by users that authenticated using
> *non* delegation token m
gt;> - I suggest this be addressed in KIP-50 as well, though it
> has
> > >> some compatibility concerns.
> >
> > Isn't KIP-50 itself one gigantic compatibility concern? I don't see
> > how your suggestions make it any worse...
> >
rrency issues, especially because the Authorizer
> interface
> exposes no details about propagating the ACLs to other nodes.
> - See Request Forwarding
>
> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+op
[
https://issues.apache.org/jira/browse/KAFKA-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-2946:
---
Status: Patch Available (was: In Progress)
> DeleteTopic - protocol and server side implementat
ient` if that's what they need.
> > > > 2. Like Grant, I'm unsure that will generally be used in a positive
> > way.
> > > > However, if this is what we need to be able to deprecate server
> > > auto-topic
> > > > creation,
Grant Henke created KAFKA-3934:
--
Summary: kafka-server-start.sh enables GC by default with no way
to disable
Key: KAFKA-3934
URL: https://issues.apache.org/jira/browse/KAFKA-3934
Project: Kafka
n every application.
> >
> > If people like this approach, perhaps we could define a topic spec (if
> all
> > fields besides topic name are empty it use "cluster defaults"). Then the
> > AdminClient would have an idempotent create method that takes a spec
; of a transition for people relying on the current behavior.
>
> I kind of feel once you start adding AdminClient methods to the producer
> and consumer it's not really clear where to stop--e.g. if I can create I
> should be able to delete, list, etc.
>
> -Jay
>
Grant
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
://github.com/apache/kafka/pull/1489
On Fri, Jun 24, 2016 at 5:43 PM, Gwen Shapira wrote:
> +1
>
> On Thu, Jun 23, 2016 at 8:32 PM, Grant Henke wrote:
> > I would like to initiate the voting process for the "KIP-4 Delete Topics
> > Schema changes". This is not a vote for all o
nningAsBroker".
> >> 2. It's not a useful state.
> >> a. If clients want to use this metric to know whether a broker is
> ready
> >> to receive requests or not, they do not care whether or not the broker
> is
> >> the controller
> >>
ay/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations#KIP-4-Commandlineandcentralizedadministrativeoperations-DeleteTopicsRequest(KAFKA-2946)>*
A sample patch is on github:
https://github.com/granthenke/kafka/tree/delete-wire-new
Note: This branch and patch is based on the CreateTopic request/response
PR. I will open a PR once that patch is complete.
Here is a link to the past discussion on the mailing list:
*http://search-hadoop.com/m/uyzND1fokOBn6uNd2&subj=+DISCUSS+KIP+4+Delete+Topic+Schema
<http://search-hadoop.com/m/uyzND1fokOBn6uNd2&subj=+DISCUSS+KIP+4+Delete+Topic+Schema>*
Thank you,
Grant
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
gt;
> > > >> On Mon, Jun 20, 2016, at 11:33 AM, Ismael Juma wrote:
> > > >> > +1 (binding)
> > > >> >
> > > >> > On Mon, Jun 20, 2016 at 8:27 PM, Dana Powers <
> dana.pow...@gmail.com
> > >
> > >
ume the
> > message was
> > > valid and the topic deletion was triggered.
> >
> > In the timeout <= 0 case, if the client should always ignore and treat
> the timeout
> > error code as "OK", should we just return no error code in this case?
>
he topics that did not "complete" in time. This allows the client
to know which topics actions completed and which timed out. I updated the
wiki to explicitly call this out in the response section.
Thanks,
Grant
On Tue, Jun 21, 2016 at 5:44 AM, Ismael Juma wrote:
> Thanks Grant
operations-request>
>below
>
> Delete Topics Response
>
>
>
> DeleteTopics Response (Version: 0) => [topic_error_codes]
> topic_error_codes => topic error_code
> topic => STRING
> error_code => INT16
>
> DeleteTopicsResponse is si
2016, at 04:15 PM, Guozhang Wang wrote:
> > > +1.
> > >
> > > On Thu, Jun 16, 2016 at 3:47 PM, Ismael Juma
> wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > On Thu, Jun 16, 2016 at 11:50 PM, Grant Henke
> > wrote:
&
r the
> > topics that violated those constraints in the request and handle them
> > accordingly with the right error code w/o disconnecting.
> >
> > Thanks,
> >
> > Jun
> >
> > On Fri, Jun 17, 2016 at 8:40 AM, Dana Powers
> > wrote:
> &
te_topic_request, not the entire connection? The
> CreateTopicsResponse returns a map of topics to error codes. You could
> just return the topic that caused the error and an
> InvalidRequestException error code.
>
> -Dana
>
> On Thu, Jun 16, 2016 at 8:37 AM, Grant Henke wrote
d+thread
> > > > > > .
> > > > > >
> > > > > > After some discussion on this list, I think we were in agreement
> > that
> > > > > this
> > > > > > change addresses a major part of the problem and we've left the
> > door
> > > > open
> > > > > > for further improvements, such as adding a heartbeat() API or a
> > > > > separately
> > > > > > configured rebalance timeout. Thanks in advance to everyone who
> > helped
> > > > > > review the proposal.
> > > > > >
> > > > > > -Jason
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -- Guozhang
> > > > >
> > > >
> >
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
t(KAFKA-2945)
<https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations#KIP-4-Commandlineandcentralizedadministrativeoperations-CreateTopicsRequest(KAFKA-2945)>*
A pull request is available implementing the proposed changes here:
https://github.com/apache/kafka/pull/1489
Here is a link to the past discussion on the mailing list:
*http://search-hadoop.com/m/uyzND1rfG6v1oixmZ&subj=+DISCUSS+KIP+4+Create+Topic+Schema
<http://search-hadoop.com/m/uyzND1rfG6v1oixmZ&subj=+DISCUSS+KIP+4+Create+Topic+Schema>*
Thank you,
Grant
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
s may still be using Java 7 by the time Kafka 0.10.1.0 is
> > released.
> > > > > More specifically, we care about the subset who would be able to
> > > upgrade
> > > > to
> > > > > Kafka 0.10.1.0, but would not be able to upgrade the Java version.
> It
> > > > would
> > > > > be great if we could quantify this in some way.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Ismael
> > > > >
> > > > > [1] https://java.com/en/download/faq/java_7.xml
> > > > > [2]
> > https://blogs.oracle.com/thejavatutorials/entry/jdk_8_is_released
> > > > > [3] http://openjdk.java.net/projects/jdk9/
> > > > > [4] https://github.com/apache/cassandra/blob/trunk/README.asc
> > > > > [5]
> > > https://lucene.apache.org/#highlights-of-this-lucene-release-include
> > > > > [6] http://akka.io/news/2015/09/30/akka-2.4.0-released.html
> > > > > [7] https://issues.apache.org/jira/browse/HADOOP-11858
> > > > > [8] https://webtide.com/jetty-9-3-features/
> > > > > [9] http://markmail.org/message/l7s276y3xkga2eqf
> > > > > [10]
> > > > >
> > > > >
> > > >
> > >
> >
> https://intellij-support.jetbrains.com/hc/en-us/articles/206544879-Selecting-the-JDK-version-the-IDE-will-run-under
> > > > > [11] http://markmail.org/message/l7s276y3xkga2eqf
> > > > >
> > > >
> > >
> >
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
nistrativeoperations-request>
>below
>
> Create Topics Response
>
>
>
> CreateTopics Response (Version: 0) => [topic_error_codes]
> topic_error_codes => topic error_code
> topic => STRING
> error_code => INT16
>
> CreateTopicsRes
; > On Wed, Jun 15, 2016 at 6:52 PM, Grant Henke
> wrote:
> >>
> >> The one thing I want to avoid is to many super specific error codes. I
> am
> >> not sure how much of a problem it really is but in the case of wire
> >> protocol errors like multiple inst
[
https://issues.apache.org/jira/browse/KAFKA-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15332524#comment-15332524
]
Grant Henke commented on KAFKA-3818:
A few older threads mention that its possibl
e in the protocol? In the code, negative timeouts are typically
> disallowed or they mean an infinite timeout (we have moved from the latter
> to the former in some of the Java networking code in recent releases).
> Ismael
>
> On Tue, Jun 14, 2016 at 11:51 PM, Grant Henke wrote:
>
&
[
https://issues.apache.org/jira/browse/KAFKA-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-3691:
---
Fix Version/s: 0.10.0.1
> Confusing logging during metadata update time
[
https://issues.apache.org/jira/browse/KAFKA-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-3691:
---
Fix Version/s: 0.10.1.0
> Confusing logging during metadata update time
[
https://issues.apache.org/jira/browse/KAFKA-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-3691:
---
Affects Version/s: 0.10.0.0
> Confusing logging during metadata update time
[
https://issues.apache.org/jira/browse/KAFKA-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-3691:
---
Status: Patch Available (was: Open)
> Confusing logging during metadata update time
; Should it be `CreateTopicsRequest` then?
>
Sure, I will update that in the patch and wiki.
P.S. I fixed a couple of typos I spotted on the wiki page, I hope that's OK.
>
Absolutely. Feel free to improve the wiki anytime.
Thanks,
Grant
On Tue, Jun 14, 2016 at 3:09 PM, Ismael
s, and different error codes are returned.
>
> Guozhang
>
>
>
> On Mon, Jun 13, 2016 at 6:54 PM, Grant Henke wrote:
>
> > Thanks for the review Jun.
> >
> > You probably want to make it clearer if timeout > 0, what waiting for
> topic
> > > meta
the first implementation, it really means
> that the topic metadata is propagated to the controller's metadata cache.
>
> Jun
>
> On Fri, Jun 10, 2016 at 9:21 AM, Grant Henke wrote:
>
> > Now that Kafka 0.10 has been released I would like to start work on the
>
"ack" from replicas, we will be able to add the new behavior without
> changing the protocol (just the semantics of waiting).
>
> Gwen
>
> On Fri, Jun 10, 2016 at 7:21 PM, Grant Henke wrote:
> > Now that Kafka 0.10 has been released I would like to start work o
ch would
> maintain its own connection pool etc, would be used internally by the
> producer (and potentially consumer) or if they would just reuse the request
> objects.
>
> Just trying to write this down to sanity check that it will work.
>
> -Jay
>
> On Fri, Jun 10, 2016
Response (Version: 0) => [topic_error_codes]
> topic_error_codes => topic error_code
> topic => STRING
> error_code => INT16
>
> CreateTopicResponse contains a map between topic and topic creation
> result error code (see New Protocol Errors
> <https://cwi
[
https://issues.apache.org/jira/browse/KAFKA-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KAFKA-3789:
---
Status: Patch Available (was: Open)
> Upgrade Snappy to fix snappy decompression err
Grant Henke created KAFKA-3789:
--
Summary: Upgrade Snappy to fix snappy decompression errors
Key: KAFKA-3789
URL: https://issues.apache.org/jira/browse/KAFKA-3789
Project: Kafka
Issue Type: Bug
[
https://issues.apache.org/jira/browse/KAFKA-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke reassigned KAFKA-3764:
--
Assignee: Grant Henke
> Error processing append operation on partit
[
https://issues.apache.org/jira/browse/KAFKA-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15312916#comment-15312916
]
Grant Henke commented on KAFKA-3764:
It looks like this is likely caused by
h
Grant Henke created KAFKA-3781:
--
Summary: Errors.exceptionName() can throw NPE
Key: KAFKA-3781
URL: https://issues.apache.org/jira/browse/KAFKA-3781
Project: Kafka
Issue Type: Bug
Affects
wiki.apache.org/confluence/display/KAFKA/KIP-62%3A+Allow+consumer+to+send+heartbeats+from+a+background+thread
> .
> Have a look and let me know what you think.
>
> Thanks,
> Jason
>
--
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
have a "max" lag?
> >> And
> >>> is
> >>>>> this "lag" a bad thing?
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Jiangjie (Becket) Qin
> >>>>>
> >>&
1 - 100 of 794 matches
Mail list logo
