I just double checked the discussion thread of KIP-120 that introduced
`TopologyDescription`. Back than the argument was, that using the
simplest option might be sufficient because the description is mostly
used for debugging.
Not sure if this argument holds. It seem that people built first more
John,
I am a little bit on the fence. In retrospective, it might have been
better to add `topic()` and `topicPattern()` to source node and return a
proper `Pattern` object instead of the pattern as a String.
All other "payload" is just names and thus String naturally. From my
point of view
John, that was fantastic, man!
Have you built any custom implementation of your KIP in your machine so that I
could test it out here? I wish I could test it out.
If you need any help implementing this feature, please tell me.
Thanks.
-Flávio Stutz
On 2018/07/03 18:04:52, John Roesler
There are some concerns about the incremental option that needs to be
discussed further.
I believe everyone agrees on the need for incremental updates, allowing a
client
to only alter the configuration it provides in an atomic fashion.
The proposal adds a request-level incremental bool for this
+1 (non-binding)
Ran tests and quickstart using kafka_2.12-2.0.0.tgz with Java 8
Thanks
On Wed, Jul 4, 2018 at 10:24 AM, Manikumar wrote:
> +1 (non-binding) Verified the release notes, src, binary artifacts, Ran
> the test suite,
> Verified quick start, Ran producer/consumer perf test, log
+1 (non-binding)
On Wed, Jul 4, 2018 at 5:22 PM Magnus Edenhill wrote:
> +1 (non-binding)
>
> 2018-07-04 13:40 GMT+02:00 Satish Duggana :
>
> > +1
> >
> > Thanks,
> > Satish.
> >
> > On Wed, Jul 4, 2018 at 4:11 PM, Daniele Ascione
> > wrote:
> >
> > > +1
> > >
> > > Thanks,
> > > Daniele
> > >
+1
Thanks,
Satish.
On Wed, Jul 4, 2018 at 4:11 PM, Daniele Ascione wrote:
> +1
>
> Thanks,
> Daniele
>
> Il giorno mar 3 lug 2018 alle ore 23:55 Harsha ha
> scritto:
>
> > +1.
> >
> > Thanks,
> > Harsha
> >
> > On Tue, Jul 3rd, 2018 at 9:22 AM, Ted Yu wrote:
> >
> > >
> > >
> > >
> > > +1
>
+1 (non-binding)
2018-07-04 13:40 GMT+02:00 Satish Duggana :
> +1
>
> Thanks,
> Satish.
>
> On Wed, Jul 4, 2018 at 4:11 PM, Daniele Ascione
> wrote:
>
> > +1
> >
> > Thanks,
> > Daniele
> >
> > Il giorno mar 3 lug 2018 alle ore 23:55 Harsha ha
> > scritto:
> >
> > > +1.
> > >
> > > Thanks,
> >
Richard Yu created KAFKA-7132:
-
Summary: Consider adding multithreaded form of recovery
Key: KAFKA-7132
URL: https://issues.apache.org/jira/browse/KAFKA-7132
Project: Kafka
Issue Type:
Thanks for driving the release, Matthias!
On Tue, Jul 3, 2018 at 10:08 PM, Jason Gustafson wrote:
> Awesome. Thanks Matthias!
>
> On Tue, Jul 3, 2018 at 12:44 PM, Yishun Guan wrote:
>
> > Nice! Thanks~
> >
> > On Tue, Jul 3, 2018, 12:16 PM Ismael Juma wrote:
> >
> > > Thanks Matthias!
> > >
>
+1
Thanks,
Daniele
Il giorno mar 3 lug 2018 alle ore 23:55 Harsha ha scritto:
> +1.
>
> Thanks,
> Harsha
>
> On Tue, Jul 3rd, 2018 at 9:22 AM, Ted Yu wrote:
>
> >
> >
> >
> > +1
> >
> > On Tue, Jul 3, 2018 at 9:05 AM, Mickael Maison <
> mickael.mai...@gmail.com >
> >
> > wrote:
> >
> > > +1
+1 (non-binding) Verified the release notes, src, binary artifacts, Ran
the test suite,
Verified quick start, Ran producer/consumer perf test, log compaction tests
Thanks
On Wed, Jul 4, 2018 at 8:33 AM Brett Rann wrote:
> +1 tentative
> rolling upgrade of tiny shared staging multitenacy
Hi Viktor,
Where are we with this KIP? Is it just waiting for votes? We should try and
get this in earlier in the release cycle this time.
Thank you,
Rajini
On Mon, May 21, 2018 at 7:44 AM, Viktor Somogyi
wrote:
> Hi All,
>
> I'd like to ask the community to please vote for this as the KIP
>
Thanks for driving the release, Matthias!
On Tue, Jul 3, 2018 at 8:48 PM, Matthias J. Sax wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> The Apache Kafka community is pleased to announce the release for
> Apache Kafka 0.10.2.2.
>
>
> This is a bug fix release and it includes
*Hi All,The vote has passed with 3 binding votes (Dong Lin, Rajini, Jason,)
and one non-binding vote(Ted).Thanks everyone for the
votes.Thanks,Manikumar*
On Fri, Jun 29, 2018 at 9:34 PM Jason Gustafson wrote:
> +1
>
> Thanks Manikumar!
>
> On Fri, Jun 29, 2018 at 8:37 AM, Rajini Sivaram
>
Hi,
I was filing KAFKA-7059 ([1]) and sent a PR adding a new ctor:
--
public ProducerRecord(String topic, K key, V value, Iterable
headers)
---
One reasonable comment on the PR was instead of doing constructor
overloading, why not working on a builder for the ProducerRecord class.
I think this
+1 (non binding)
On Wed, Jul 4, 2018 at 1:19 PM, Kamal Chandraprakash <
kamal.chandraprak...@gmail.com> wrote:
> +1 (non-binding)
>
> On Wed, Jul 4, 2018 at 5:22 PM Magnus Edenhill wrote:
>
> > +1 (non-binding)
> >
> > 2018-07-04 13:40 GMT+02:00 Satish Duggana :
> >
> > > +1
> > >
> > > Thanks,
Chris Schwarzfischer created KAFKA-7133:
---
Summary: DisconnectException every 5 minutes in single restore
consumer thread
Key: KAFKA-7133
URL: https://issues.apache.org/jira/browse/KAFKA-7133
hi John
> Just really scraping my mind for concerns to investigate... This change
> won't break source compatibility, but will it affect binary compatibility?
> For example, if I compile my application against Kafka 2.0, for example,
> and then swap in the Kafka jar containing your change on my
After looked through the current TopologyDescription I think I'd want to
combine the suggestions from John and Matthias on the API proposal. The
motivations is that we have two relatively different functionalities
provided from the APIs today:
1. Each interface's public functions, like
Hi Jun,
-: 1. I guess both new configurations will be at the topic level?
They will exist in the global configuration, at the very least.
I would like to have them on the topic level as well, but there is an
inconsistency between the cleanup/compaction properties that exist “only
globally” vs
Sounds good to me.
-Matthias
On 7/4/18 10:53 AM, Guozhang Wang wrote:
> After looked through the current TopologyDescription I think I'd want to
> combine the suggestions from John and Matthias on the API proposal. The
> motivations is that we have two relatively different functionalities
>
Hi Jason and Dong,
I’ve been thinking about your suggestions and discussion regarding
position(), seek(), and new proposed API.
Here is my thought process why we should keep position() and seek() API
unchanged.
I think we should separate {offset, leader epoch} that uniquely identifies
a
Hi Jason,
There’s a “Motivation” chapter in the KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-280%3A+Enhanced+log+compaction#KIP-280:Enhancedlogcompaction-Motivation
Is it still unclear after reading that?
Kind Regards,
Luís Cabral
From: Jason Gustafson
Sent: 03 July 2018 23:45
Hey everybody,
I've already implemented some JIRA tickets and would like to further my
contributions into this great project by creating KIPs. Can I receive
permission to do so?
My e-mail: stanis...@confluent.io
--
Best,
Stanislav
Hi Stanislav,
I have added access to your account `stanislav`.
Regards,
Rajini
On Wed, Jul 4, 2018 at 5:35 PM, Stanislav Kozlovski
wrote:
> Hey everybody,
>
> I've already implemented some JIRA tickets and would like to further my
> contributions into this great project by creating KIPs. Can
Thanks for the discussion. I am just catching up.
In general, I think we have different uses cases and non-windowed and
windowed is quite different. For the non-windowed case, suppress() has
no (useful) close or retention time, no final semantics, and also no
business logic impact.
On the other
Hello Ted,
That's my fault. I replied in the PR because at the time John had made his
comment I hadn't added myself to the dev email list to reply. You can see
my comment here.
https://github.com/apache/kafka/pull/5284#discussion_r199360544
There is still ongoing discussion about the purpose of
28 matches
Mail list logo