> On Wed, Aug 12, 2015 at 1:51 AM, Gwen Shapira
>> wrote:
>> >>
>> >>> Ah, there is already a JIRA in the title. Never mind :)
>> >>>
>> >>> On Tue, Aug 11, 2015 at 5:51 PM, Gwen Shapira
>> wrote:
>> >>>
>>
Bc
Sent from my iPhone
B
> On 25-Apr-2017, at 10:21, ASF GitHub Bot (JIRA) wrote:
>
>This message is eligible for Automatic Cleanup! (j...@apache.org) Add
> cleanup rule | More info
>
>[
> https://issues.apache.org/jira/browse/KAFKA-4379?page=com.atlassian.jira.plugin.system.issuetab
h) is the 0.8.2.2 tag
> https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=tag;h=d01226cfdcb3d9daad8465234750fa515a1e7e4a
>
> /***
>
> Thanks,
>
> Jun
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
On Fri, Oct 2, 2015 at 12:38 PM, Gwen Shapira wrote:
> Hi,
>
> I created asf-git under https://git-wip-us.apache.org/repos/asf/kafka-site.
> git and pushed our existing docs in there.
> What do we need to do to get infra to show this in our website?
>
> Next steps:
> 1) Minor fix to PR 171
> 2) Me
nt/12595269/298-screenshot.png
>
> Cheers,
>
> -Jay
>
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
> >> > > > >
> >> > > > > Kafka's KEYS file containing PGP keys we use to sign the
> release:
> >> > > > > http://kafka.apache.org/KEYS
> >> > > > >
> >> > > > > * Release artifacts to be voted upon (source and binary):
> >> > > > > http://home.apache.org/~gwenshap/0.10.0.0-rc6/
> >> > > > >
> >> > > > > * Maven artifacts to be voted upon:
> >> > > > > https://repository.apache.org/content/groups/staging/
> >> > > > >
> >> > > > > * java-doc
> >> > > > > http://home.apache.org/~gwenshap/0.10.0.0-rc6/javadoc/
> >> > > > >
> >> > > > > * tag to be voted upon (off 0.10.0 branch) is the 0.10.0.0 tag:
> >> > > > >
> >> > > > >
> >> > >
> >> >
> >>
>
> https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=tag;h=065899a3bc330618e420673acf9504d123b800f3
>
> >> > > > >
> >> > > > > * Documentation:
> >> > > > > http://kafka.apache.org/0100/documentation.html
> >> > > > >
> >> > > > > * Protocol:
> >> > > > > http://kafka.apache.org/0100/protocol.html
> >> > > > >
> >> > > > > /**
> >> > > > >
> >> > > > > Thanks,
> >> > > > >
> >> > > > > Gwen
> >> > > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > -- Guozhang
> >> >
> >>
> >>
> >>
> >> --
> >> Thanks,
> >> Ewen
> >>
>
>
>
>
>
>
--
Ashish 🎤h
e a `server` package
> in a `clients` jar, but that is just making explicit what is happening
> either way (we are adding a server-only interface to the `clients` jar).
>
> Thoughts?
>
> Ismael
>
> On Fri, Apr 22, 2016 at 10:56 PM, Ashish Singh
> wrote:
>
> > He
nder review. Here is the PR
<https://github.com/apache/kafka/pull/986>
I have addressed all review comments and have been waiting for further
reviews/ this to go in for quite some time. I will really appreciate if a
committer can help with making progress on this.
--
Regards,
Ashish
Provided wrong link to PR, here is the PR
<https://github.com/apache/kafka/pull/1251> for KAFKA-3600.
On Tue, Aug 9, 2016 at 9:45 AM, Ashish Singh wrote:
> Hey Guys,
>
> KAFKA-3600 <https://issues.apache.org/jira/browse/KAFKA-3600> was part of
> KIP-35's
il this flag is set, after
> the Processors started? This seems a bit tricky though.
>
> Anyone has better ideas?
>
> Gwen
>
--
Regards,
Ashish
examples/src/main/java/kafka/examples/SimpleConsumerDemo.java
0d66fe5f8819194c8624aed4a21105733c20cc8e
Diff: https://reviews.apache.org/r/31369/diff/
Testing
---
Thanks,
Ashish Singh
examples/src/main/java/kafka/examples/SimpleConsumerDemo.java
0d66fe5f8819194c8624aed4a21105733c20cc8e
Diff: https://reviews.apache.org/r/31369/diff/
Testing
---
Thanks,
Ashish Singh
> On April 7, 2015, 10:41 p.m., Jun Rao wrote:
> > Sorry for the late review. A few more comments below.
Done!
- Ashish
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31369/#re
> On March 25, 2015, 4:48 p.m., Mayuresh Gharat wrote:
> >
Thanks for the review. Addressed your comment.
- Ashish
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31369/#re
examples/src/main/java/kafka/examples/SimpleConsumerDemo.java
0d66fe5f8819194c8624aed4a21105733c20cc8e
Diff: https://reviews.apache.org/r/31369/diff/
Testing
---
Thanks,
Ashish Singh
> On April 17, 2015, 11:05 p.m., Jun Rao wrote:
> > Thanks for the patch. A few more minor comments.
Jun thanks for the review again. Addressed your comments.
- Ashish
---
This is an automatically generated e-mail. To rep
examples/src/main/java/kafka/examples/SimpleConsumerDemo.java
0d66fe5f8819194c8624aed4a21105733c20cc8e
Diff: https://reviews.apache.org/r/31369/diff/
Testing
---
Thanks,
Ashish Singh
Jun,
My apologies for not catching the checkstyle issues before. Should be fine
now. Thanks for the prompt reviews.
On Sun, Apr 19, 2015 at 1:14 AM, Ashish Singh wrote:
>This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31369/
> Review re
/log4j/KafkaLog4jAppenderTest.java
PRE-CREATION
log4j/src/test/java/org/apache/kafka/log4j/MockKafkaLog4jAppender.java
PRE-CREATION
settings.gradle 83f764e6a4a15a5fdba232dce74a369870f26b45
Diff: https://reviews.apache.org/r/33614/diff/
Testing
---
Thanks,
Ashish Singh
---
Thanks,
Ashish Singh
---
Thanks,
Ashish Singh
---
Thanks,
Ashish Singh
://reviews.apache.org/r/33645/diff/
Testing
---
Thanks,
Ashish Singh
m reusing the part of logic already present in
test-patch.py.
- Ashish
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33645/#review82076
: https://reviews.apache.org/r/33614/diff/
Testing
---
Thanks,
Ashish Singh
e why.
Honestly, I had the same question. However, I did not want to change the
original behaviour. I doubt using StringSerializer will change the behaviour,
but having byte serializer is helpful for testing as it can be easily overrided
by MockProducer. If we really have t
Diff: https://reviews.apache.org/r/33614/diff/
Testing
---
Thanks,
Ashish Singh
t;asi...@cloudera.com".
--
Regards,
Ashish
Bummer... I meant *Confluence id* :)
On Mon, May 4, 2015 at 1:48 PM, Ashish Singh wrote:
> Hello,
>
> While trying to create a KIP, I realized that I probably need to get my
> confluence id to be able to create a page under Apache Kafka. Either that
> or I am doing somethi
Thanks for extending help here. I do have a separate confluence wiki
account, https://cwiki.apache.org/confluence/display/~asingh. Below are the
details.
username: asingh
email: asi...@cloudera.com
full name: Ashish Singh
Let me know if you are still not able to find me.
On Mon, May 4, 2015 at
Thanks Jun!
On Monday, May 4, 2015, Jun Rao wrote:
> Added.
>
> Thanks,
>
> Jun
>
> On Mon, May 4, 2015 at 2:17 PM, Ashish Singh > wrote:
>
> > Thanks for extending help here. I do have a separate confluence wiki
> > account, https://cwiki.apache.or
ling for
> > whether these kinds of capabilities are of interest to others.
> >
> > Thanks in advance,
> > - Adrian
> >
> > 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
> >
> >
>
>
> 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
>
>
--
Regards,
Ashish
what "topic paths" a client has access to rather
> than needing a new client instance that connects to that separate namespace
> (a la zookeeper). I think this will be a nice way to share config and acl
> defaults too.
>
> -Jay
>
> On Tue, May 5, 2015 at 10:36 AM, Ashish Si
11 PST on May 5. The following is the agenda.
> If you want to attend and is not on the invite, please let me know.
>
> Agenda:
> KIP-4 (admin commands): any remaining issues
> KIP-11 (authorization): any remaining issues
> KIP-21 (configuration management)
>
> Thanks,
>
> Jun
>
--
Regards,
Ashish
paction (assuming we wanted to make that dynamic) we need to
> call
> > > > > shutdown() on the cleaner. I think it may be required to register a
> > > > > listener callback that gets called when the config changes.
> > > > >
> > > > > 5. For handling the reference can you explain your plan a bit?
> > > Currently we
> > > > > have an immutable KafkaConfig object with a bunch of vals. That or
> > > > > individual values in there get injected all over the code base. I
> was
> > > > > thinking something like this:
> > > > > a. We retain the KafkaConfig object as an immutable object just as
> > > today.
> > > > > b. It is no longer legit to grab values out fo that config if they
> > are
> > > > > changeable.
> > > > > c. Instead of making KafkaConfig itself mutable we make
> > > KafkaConfiguration
> > > > > which has a single volatile reference to the current KafkaConfig.
> > > > > KafkaConfiguration is what gets passed into various components. So
> to
> > > > > access a config you do something like config.instance.myValue. When
> > the
> > > > > config changes the config manager updates this reference.
> > > > > d. The KafkaConfiguration is the thing that allows doing the
> > > > > configuration.onChange("my.config", callback)
> > > > >
> > > > > -Jay
> > > > >
> > > > > On Tue, Apr 28, 2015 at 3:57 PM, Aditya Auradkar <
> > > > > aaurad...@linkedin.com.invalid> wrote:
> > > > >
> > > > > > Hey everyone,
> > > > > >
> > > > > > Wrote up a KIP to update topic, client and broker configs
> > > dynamically via
> > > > > > Zookeeper.
> > > > > >
> > > > > >
> > > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-21+-+Dynamic+Configuration
> > > > > >
> > > > > > Please read and provide feedback.
> > > > > >
> > > > > > Thanks,
> > > > > > Aditya
> > > > > >
> > > > > > PS: I've intentionally kept this discussion separate from KIP-5
> > > since I'm
> > > > > > not sure if that is actively being worked on and I wanted to
> start
> > > with a
> > > > > > clean slate.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Thanks,
> > > > Neha
> > >
> > > --
> > > Joel
> > >
> >
>
--
Regards,
Ashish
Hey Jun,
Where does the broker get the info, which zk it needs to talk to?
On Wednesday, May 6, 2015, Jun Rao wrote:
> Ashish,
>
> 3. Just want to clarify. Why can't you store ZK connection config in ZK?
> This is a property for ZK clients, not ZK server.
>
> Thanks,
&g
, May 6, 2015, Ashish Singh wrote:
> Hey Jun,
>
> Where does the broker get the info, which zk it needs to talk to?
>
> On Wednesday, May 6, 2015, Jun Rao > wrote:
>
>> Ashish,
>>
>> 3. Just want to clarify. Why can't you store ZK connection config in Z
Agreed :). However, the other concerns remain. Do you think just providing
zk info to broker will be sufficient? I will myself spend some to look into
the existing required confine.
On Thursday, May 7, 2015, Jun Rao wrote:
> Ashish,
>
> 3. This is true. However, using files has the sam
here <https://reviews.apache.org/r/28096/>.
Comments and suggestions are welcome!
--
Regards,
Ashish
Had to change the title of the page and that surprisingly changed the link
as well. KIP-23 is now available at here
<https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=56852556>.
On Thu, May 7, 2015 at 11:34 AM, Ashish Singh wrote:
> Hi Guys,
>
> I just added a KI
> > > each
> > > > > > > > > > > Puppet agent has to read it from ZK, this means the ZK
> > port
> > > > has
> > > > > > to
> > > > > > > be
> > > > > > > > > > open
> > > > > > > > > > > to pretty much every machine in the DC. This is a
> bummer
> > and
> > > > a
> > > > > > very
> > > > > > > > > > > confusing requirement. Not sure if this is really a
> > problem
> > > > or
> > > > > > not
> > > > > > > > > (each
> > > > > > > > > > of
> > > > > > > > > > > those tools might behave differently), though pointing
> > out
> > > > that
> > > > > > > this
> > > > > > > > is
> > > > > > > > > > > something worth paying attention to.
> > > > > > > > > > >
> > > > > > > > > > > 3. The wrapper tools that let users read/change config
> > tools
> > > > > > should
> > > > > > > > not
> > > > > > > > > > > depend on ZK for the reason mentioned above. It's a
> pain
> > to
> > > > > > assume
> > > > > > > > that
> > > > > > > > > > the
> > > > > > > > > > > ZK port is open from any machine that needs to run this
> > tool.
> > > > > > > Ideally
> > > > > > > > > > what
> > > > > > > > > > > users want is a REST API to the brokers to change or
> > read the
> > > > > > > config
> > > > > > > > > (ala
> > > > > > > > > > > Elasticsearch), but in the absence of the REST API, we
> > should
> > > > > > think
> > > > > > > > if
> > > > > > > > > we
> > > > > > > > > > > can write the tool such that it just requires talking
> to
> > the
> > > > > > Kafka
> > > > > > > > > broker
> > > > > > > > > > > port. This will require a config RPC.
> > > > > > > > > > >
> > > > > > > > > > > 4. Not sure if KIP is the right place to discuss the
> > design
> > > > of
> > > > > > > > > > propagating
> > > > > > > > > > > the config changes to the brokers, but have you thought
> > about
> > > > > > just
> > > > > > > > > > letting
> > > > > > > > > > > the controller oversee the config changes and propagate
> > via
> > > > RPC
> > > > > > to
> > > > > > > > the
> > > > > > > > > > > brokers? That way, there is an easier way to express
> > config
> > > > > > changes
> > > > > > > > > that
> > > > > > > > > > > require all brokers to change it for it to be called
> > > > complete.
> > > > > > > Maybe
> > > > > > > > > this
> > > > > > > > > > > is not required, but it is hard to say if we don't
> > discuss
> > > > the
> > > > > > full
> > > > > > > > set
> > > > > > > > > > of
> > > > > > > > > > > configs that need to be dynamic.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Neha
> > > > > > > > > > >
> > > > > > > > > > > On Fri, May 1, 2015 at 12:53 PM, Jay Kreps <
> > > > > jay.kr...@gmail.com >
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hey Aditya,
> > > > > > > > > > > >
> > > > > > > > > > > > This is a great! A couple of comments:
> > > > > > > > > > > >
> > > > > > > > > > > > 1. Leaving the file config in place is definitely the
> > least
> > > > > > > > > > disturbance.
> > > > > > > > > > > > But let's really think about getting rid of the files
> > and
> > > > > just
> > > > > > > have
> > > > > > > > > one
> > > > > > > > > > > > config mechanism. There is always a tendency to make
> > > > > everything
> > > > > > > > > > pluggable
> > > > > > > > > > > > which so often just leads to two mediocre solutions.
> > Can we
> > > > > do
> > > > > > > the
> > > > > > > > > > exercise
> > > > > > > > > > > > of trying to consider fully getting rid of file
> config
> > and
> > > > > > seeing
> > > > > > > > > what
> > > > > > > > > > goes
> > > > > > > > > > > > wrong?
> > > > > > > > > > > >
> > > > > > > > > > > > 2. Do we need to model defaults? The current approach
> > is
> > > > that
> > > > > > if
> > > > > > > > you
> > > > > > > > > > have a
> > > > > > > > > > > > global config x it is overridden for a topic xyz by
> > > > > > > /topics/xyz/x,
> > > > > > > > > and
> > > > > > > > > > I
> > > > > > > > > > > > think this could be extended to /brokers/0/x. I think
> > this
> > > > is
> > > > > > > > > simpler.
> > > > > > > > > > We
> > > > > > > > > > > > need to specify the precedence for these overrides,
> > e.g. if
> > > > > you
> > > > > > > > > > override at
> > > > > > > > > > > > the broker and topic level I think the topic level
> > takes
> > > > > > > > precedence.
> > > > > > > > > > > >
> > > > > > > > > > > > 3. I recommend we have the producer and consumer
> config
> > > > just
> > > > > be
> > > > > > > an
> > > > > > > > > > override
> > > > > > > > > > > > under client.id. The override is by client id and we
> > can
> > > > > have
> > > > > > > > > separate
> > > > > > > > > > > > properties for controlling quotas for producers and
> > > > > consumers.
> > > > > > > > > > > >
> > > > > > > > > > > > 4. Some configs can be changed just by updating the
> > > > > reference,
> > > > > > > > others
> > > > > > > > > > may
> > > > > > > > > > > > require some action. An example of this is if you
> want
> > to
> > > > > > disable
> > > > > > > > log
> > > > > > > > > > > > compaction (assuming we wanted to make that dynamic)
> we
> > > > need
> > > > > to
> > > > > > > > call
> > > > > > > > > > > > shutdown() on the cleaner. I think it may be required
> > to
> > > > > > > register a
> > > > > > > > > > > > listener callback that gets called when the config
> > changes.
> > > > > > > > > > > >
> > > > > > > > > > > > 5. For handling the reference can you explain your
> > plan a
> > > > > bit?
> > > > > > > > > > Currently we
> > > > > > > > > > > > have an immutable KafkaConfig object with a bunch of
> > vals.
> > > > > That
> > > > > > > or
> > > > > > > > > > > > individual values in there get injected all over the
> > code
> > > > > > base. I
> > > > > > > > was
> > > > > > > > > > > > thinking something like this:
> > > > > > > > > > > > a. We retain the KafkaConfig object as an immutable
> > object
> > > > > just
> > > > > > > as
> > > > > > > > > > today.
> > > > > > > > > > > > b. It is no longer legit to grab values out fo that
> > config
> > > > if
> > > > > > > they
> > > > > > > > > are
> > > > > > > > > > > > changeable.
> > > > > > > > > > > > c. Instead of making KafkaConfig itself mutable we
> make
> > > > > > > > > > KafkaConfiguration
> > > > > > > > > > > > which has a single volatile reference to the current
> > > > > > KafkaConfig.
> > > > > > > > > > > > KafkaConfiguration is what gets passed into various
> > > > > components.
> > > > > > > So
> > > > > > > > to
> > > > > > > > > > > > access a config you do something like
> > > > > config.instance.myValue.
> > > > > > > When
> > > > > > > > > the
> > > > > > > > > > > > config changes the config manager updates this
> > reference.
> > > > > > > > > > > > d. The KafkaConfiguration is the thing that allows
> > doing
> > > > the
> > > > > > > > > > > > configuration.onChange("my.config", callback)
> > > > > > > > > > > >
> > > > > > > > > > > > -Jay
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Apr 28, 2015 at 3:57 PM, Aditya Auradkar <
> > > > > > > > > > > > aaurad...@linkedin.com.invalid> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hey everyone,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Wrote up a KIP to update topic, client and broker
> > configs
> > > > > > > > > > dynamically via
> > > > > > > > > > > > > Zookeeper.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-21+-+Dynamic+Configuration
> > > > > > > > > > > > >
> > > > > > > > > > > > > Please read and provide feedback.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Aditya
> > > > > > > > > > > > >
> > > > > > > > > > > > > PS: I've intentionally kept this discussion
> separate
> > from
> > > > > > KIP-5
> > > > > > > > > > since I'm
> > > > > > > > > > > > > not sure if that is actively being worked on and I
> > wanted
> > > > > to
> > > > > > > > start
> > > > > > > > > > with a
> > > > > > > > > > > > > clean slate.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Neha
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Joel
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> >
>
--
Ashish 🎤h
changes, via alter topic or
alter config. Agreement on going with alter config and describe config.
- Alter topic probably not required.
- Some discussion on how to delete a config override.
​
--
Regards,
Ashish
ssion thread on KIP-25
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP+-+25+System+test+improvements
> > >
> > > Thanks,
> > > Geoff
> > >
> >
>
--
Regards,
Ashish
t; KIP-21 (configuration management)
> KIP-19 (Add a request timeout to NetworkClient)
> KIP-25 (system test): quick overview
>
> Thanks,
>
> Jun
>
--
Regards,
Ashish
troller moves? The get should fail right? The client will
> > then
> > > > > > > need to connect to the new controller and reissue the request
> > but
> > > > > > > will then get ReassignPartitionsInProgress. So in that case
> the
> > > > > > > client any way needs to rely in verifyReassignPartitions.
> > > > > > > - In past hangouts I think either you/Joe were mentioning the
> > need
> > > to
> > > > > > > locate the controller (and possibly other cluster metadata).
> It
> > > > > > > appears we decided to defer this for a future KIP. Correct?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Joel
> > > > > > >
> > > > > > > On Tue, May 05, 2015 at 04:49:27PM +0300, Andrii Biletskyi
> wrote:
> > > > > > > > Guys,
> > > > > > > >
> > > > > > > > I've updated the wiki to reflect all previously discussed
> items
> > > > > > > > (regarding the schema only - this is included to phase 1).
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations
> > > > > > > >
> > > > > > > > I think we can have the final discussion today (for phase 1)
> > and
> > > > > > > > in case no new remarks I will start the voting thread.
> > > > > > > >
> > > > > > > > With regards to AlterTopicRequest semantics. I agree with
> Jun,
> > > > > > > > and I think it's my bad I focused on "multiple topics in one
> > > > > request".
> > > > > > > > The same situation is possible in ProduceRequest, Fetch,
> > > > > TopicMetadata
> > > > > > > > and we handle it naturally and in the most transparent way -
> we
> > > > > > > > put all separate instructions into a map and thus silently
> > ignore
> > > > > > > > duplicates.
> > > > > > > > This also makes Response part simple too - it's just a map
> > > > > > > Topic->ErrorCode.
> > > > > > > > I think we need to follow the same approach for Alter (and
> > > Create,
> > > > > > > Delete)
> > > > > > > > request. With this we add nothing new in terms of batch
> > requests
> > > > > > > > semantics.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Andrii Biletskyi
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -Regards,
> > > > > Mayuresh R. Gharat
> > > > > (862) 250-7125
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -Regards,
> > > Mayuresh R. Gharat
> > > (862) 250-7125
> > >
> >
>
--
Regards,
Ashish
cerns if I
> split it into 3 tables (adopted, discarded and KIP's under discussion)?
>
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
>
> Aditya
>
>
--
Regards,
Ashish
is no
> objection to this. However, Joel will follow up on this to see whether it's
> better to piggyback ISR in the fetch response itself.
How are we then addressing incorrect ISR information in
TopicMetadataResponse?
>
> Thanks,
>
> Jun
>
--
Ashish 🎤h
Please subscribe me to this group
icy. If you're interested, please check out:
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 97%3A+Improved+Kafka+Compatibility+Policy
> >
> > cheers,
> > Colin
>
--
Regards,
Ashish
On Tue, Nov 29, 2016 at 4:11 PM, Colin McCabe wrote:
> On Tue, Nov 29, 2016, at 11:39, Ashish Singh wrote:
> > Hello Colin,
> >
> > In the KIP you mentioned that currently the client uses supported api
> > versions information to check if the server supports its de
happy to
rebase KAFKA-3600 on trunk. However, any comments/ feedback on KAFKA-3600's
approach on maintaining api version info for each connected broker is
highly welcome.
On Wed, Nov 30, 2016 at 5:47 AM, Ismael Juma wrote:
> Thanks Colin, I think this is a good improvement.
>
> Ashis
On Wed, Nov 30, 2016, at 11:17, Colin McCabe wrote:
> > Thanks, Ashish. I think the idea of having the client make an
> > ApiVersionRequest call when it starts up is a good one. This idea is
> > described in both KIP-97, and the KAFKA-3600 patches. I also think we
> > ought
upport ACL's with out kerberos/SSL?
>
> Any info on this would be greatly helpful.
>
>
> Thanks
>
--
Regards,
Ashish
e). So Kerberos and SSL are not required (although commonly used).
>
> Ismael
>
> On Fri, Dec 9, 2016 at 6:59 PM, Ashish Singh wrote:
>
> > Hey,
> >
> > No it does not. Without kerberos or ssl, all requests will appear to come
> > from anonymous user, and
with the following:
>
> 1. Protocol and Config changes
>
> 2. format of the data stored in ZK.
>
> 3. Changes to Java Clients/Usage of SASL SCRAM mechanism
>
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
>
> 48+Delegation+token+support+f
?focusedCommentId=14277439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14277439
How to run:
python dev-utils/test-patch.py --defect KAFKA-1664 --username
--password --run-tests --post-results
Thanks,
Ashish Singh
views.apache.org/r/29893/diff/1/?file=821575#file821575line173>
> >
> > Where do these errors end up? will we see them in the JIRA? or in
> > Jenkins?
git_cleanup() is called after patchTesting has been completed, passed or
failed, before exiting the process. I
name
--password --run-tests --post-results
Thanks,
Ashish Singh
://reviews.apache.org/r/30259/diff/
Testing
---
Thanks,
Ashish Singh
.
Thanks,
Ashish Singh
/ZkUtils.scala
c14bd455b6642f5e6eb254670bef9f57ae41d6cb
core/src/test/scala/unit/kafka/zk/ZKPathTest.scala PRE-CREATION
Diff: https://reviews.apache.org/r/28108/diff/
Testing
---
Tested with and without the fix.
Thanks,
Ashish Singh
core/src/test/scala/unit/kafka/zk/ZKPathTest.scala, line 63
> > <https://reviews.apache.org/r/28108/diff/3/?file=789148#file789148line63>
> >
> > typo: zkConnectWithInvaidRoot
Good catch!
- Ashish
---
This is an
oject. I will create an issue and put that in the TODO as well.
- Ashish
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30259/#review69727
---
sonar will be available.
Thanks,
Ashish Singh
> On Jan. 27, 2015, 1:39 a.m., Eric Olander wrote:
> > This is a nice improvement to the project. Thanks!
Thanks for the review. Addressed your concern.
- Ashish
---
This is an automatically generated e-mail. To reply, vis
we continue to expand the
> set of contributors.
>
> -Jay
>
--
Regards,
Ashish
>>>>>>>>>>> kafka.utils.ZkUtils$.readDataMaybeNull(ZkUtils.scala:456)
> > > >>>>>>>>>>>> at
> > kafka.utils.ZkUtils$.getController(ZkUtils.scala:65)
> > > >>>>>>>>>>>> at
> > kafka.server.KafkaServer.kafka$server$KafkaServer$$
> > > >>>>>>>>>>>> controlledShutdown(KafkaServer.scala:194)
> > > >>>>>>>>>>>> at kafka.server.KafkaServer$$
> > > >>>>>>>>>>>> anonfun$shutdown$1.apply$mcV$
> > > >>>>>>>>>>>> sp(KafkaServer.scala:269)
> > > >>>>>>>>>>>> at kafka.utils.Utils$.swallow(Utils.scala:172)
> > > >>>>>>>>>>>> at kafka.utils.Logging$class.
> > > >>>>>>>>>>>> swallowWarn(Logging.scala:92)
> > > >>>>>>>>>>>> at kafka.utils.Utils$.swallowWarn(Utils.scala:45)
> > > >>>>>>>>>>>> at
> > kafka.utils.Logging$class.swallow(Logging.scala:94)
> > > >>>>>>>>>>>> at kafka.utils.Utils$.swallow(Utils.scala:45)
> > > >>>>>>>>>>>> at
> > kafka.server.KafkaServer.shutdown(KafkaServer.scala:
> > > >>>>>>>>>>>> 269)
> > > >>>>>>>>>>>> at kafka.server.KafkaServerStartable.shutdown(
> > > >>>>>>>>>>>> KafkaServerStartable.scala:42)
> > > >>>>>>>>>>>> at kafka.Kafka$$anon$1.run(Kafka.scala:42)
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> -Jaikiran
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Monday 26 January 2015 05:46 AM, Neha Narkhede wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>For a clean shutdown, the broker tries to talk to the
> > > >>>>>>>>>>>> controller
> > > >>>>>>>>>>>> and
> > > >>>>>>>>>>>> also
> > > >>>>>>>>>>>> issues reads to zookeeper. Possibly that is where it tries
> > to
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> reconnect
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> to
> > > >>>>>>>>>>>> zk. It will help to look at the thread dump.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thanks
> > > >>>>>>>>>>>>> Neha
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Fri, Jan 23, 2015 at 8:53 PM, Jaikiran Pai <
> > > >>>>>>>>>>>>> jai.forums2...@gmail.com
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I was just playing around with the RC2 of 0.8.2 and
> > > >>>>>>>>>>>>> noticed
> > > >>>>>>>>>>>>> that
> > > >>>>>>>>>>>>> if I
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> shutdown zookeeper first I can't shutdown Kafka server
> at
> > all
> > > >>>>>>>>>>>>>> since
> > > >>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>> goes
> > > >>>>>>>>>>>>>> into a never ending attempt to reconnect with zookeeper.
> > I had
> > > >>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>> kill
> > > >>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>> Kafka process to stop it. I tried it against trunk too
> and
> > > >>>>>>>>>>>>>> there
> > > >>>>>>>>>>>>>> too I
> > > >>>>>>>>>>>>>> see
> > > >>>>>>>>>>>>>> the same issue. Should I file a JIRA for this and see if
> > I can
> > > >>>>>>>>>>>>>> come
> > > >>>>>>>>>>>>>> up
> > > >>>>>>>>>>>>>> with
> > > >>>>>>>>>>>>>> a patch?
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> FWIW, here's the unending (and IMO too frequent)
> attempts
> > at
> > > >>>>>>>>>>>>>> trying
> > > >>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>> reconnect. I've a thread dump too which shows that the
> > other
> > > >>>>>>>>>>>>>> thread
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> which
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> is trying to complete a controlled shutdown of Kafka is
> > blocked
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> forever
> > > >>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>> the zookeeper to be up. I can attach it to the JIRA.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 2015-01-24 10:15:46,278] WARN Session 0x14b1a413680
> > for
> > > >>>>>>>>>>>>>> server
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> null,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> unexpected error, closing socket connection and attempting
> > > >>>>>>>>>>>> reconnect
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> (org.apache.zookeeper.ClientCnxn)
> > > >>>>>>>>>>>>>> java.net.ConnectException: Connection refused
> > > >>>>>>>>>>>>>> at
> > sun.nio.ch.SocketChannelImpl.checkConnect(Native
> > > >>>>>>>>>>>>>> Method)
> > > >>>>>>>>>>>>>> at sun.nio.ch.SocketChannelImpl.finishConnect(
> > > >>>>>>>>>>>>>> SocketChannelImpl.java:739)
> > > >>>>>>>>>>>>>> at org.apache.zookeeper.ClientCnxnSocketNIO.
> > > >>>>>>>>>>>>>> doTransport(
> > > >>>>>>>>>>>>>> ClientCnxnSocketNIO.java:361)
> > > >>>>>>>>>>>>>> at
> > org.apache.zookeeper.ClientCnxn$SendThread.run(
> > > >>>>>>>>>>>>>> ClientCnxn.java:1081)
> > > >>>>>>>>>>>>>> [2015-01-24 10:15:47,437] INFO Opening socket connection
> > to
> > > >>>>>>>>>>>>>> server
> > > >>>>>>>>>>>>>> localhost/127.0.0.1:2181. Will not attempt to
> > authenticate
> > > >>>>>>>>>>>>>> using
> > > >>>>>>>>>>>>>> SASL
> > > >>>>>>>>>>>>>> (unknown error) (org.apache.zookeeper.ClientCnxn)
> > > >>>>>>>>>>>>>> [2015-01-24 10:15:47,438] WARN Session 0x14b1a413680
> > for
> > > >>>>>>>>>>>>>> server
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> null,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> unexpected error, closing socket connection and attempting
> > > >>>>>>>>>>>> reconnect
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> (org.apache.zookeeper.ClientCnxn)
> > > >>>>>>>>>>>>>> java.net.ConnectException: Connection refused
> > > >>>>>>>>>>>>>> at
> > sun.nio.ch.SocketChannelImpl.checkConnect(Native
> > > >>>>>>>>>>>>>> Method)
> > > >>>>>>>>>>>>>> at sun.nio.ch.SocketChannelImpl.finishConnect(
> > > >>>>>>>>>>>>>> SocketChannelImpl.java:739)
> > > >>>>>>>>>>>>>> at org.apache.zookeeper.ClientCnxnSocketNIO.
> > > >>>>>>>>>>>>>> doTransport(
> > > >>>>>>>>>>>>>> ClientCnxnSocketNIO.java:361)
> > > >>>>>>>>>>>>>> at
> > org.apache.zookeeper.ClientCnxn$SendThread.run(
> > > >>>>>>>>>>>>>> ClientCnxn.java:1081)
> > > >>>>>>>>>>>>>> [2015-01-24 10:15:49,056] INFO Opening socket connection
> > to
> > > >>>>>>>>>>>>>> server
> > > >>>>>>>>>>>>>> localhost/127.0.0.1:2181. Will not attempt to
> > authenticate
> > > >>>>>>>>>>>>>> using
> > > >>>>>>>>>>>>>> SASL
> > > >>>>>>>>>>>>>> (unknown error) (org.apache.zookeeper.ClientCnxn)
> > > >>>>>>>>>>>>>> [2015-01-24 10:15:49,057] WARN Session 0x14b1a413680
> > for
> > > >>>>>>>>>>>>>> server
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> null,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> unexpected error, closing socket connection and attempting
> > > >>>>>>>>>>>> reconnect
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> (org.apache.zookeeper.ClientCnxn)
> > > >>>>>>>>>>>>>> java.net.ConnectException: Connection refused
> > > >>>>>>>>>>>>>> at
> > sun.nio.ch.SocketChannelImpl.checkConnect(Native
> > > >>>>>>>>>>>>>> Method)
> > > >>>>>>>>>>>>>> at sun.nio.ch.SocketChannelImpl.finishConnect(
> > > >>>>>>>>>>>>>> SocketChannelImpl.java:739)
> > > >>>>>>>>>>>>>> at org.apache.zookeeper.ClientCnxnSocketNIO.
> > > >>>>>>>>>>>>>> doTransport(
> > > >>>>>>>>>>>>>> ClientCnxnSocketNIO.java:361)
> > > >>>>>>>>>>>>>> at
> > org.apache.zookeeper.ClientCnxn$SendThread.run(
> > > >>>>>>>>>>>>>> ClientCnxn.java:1081)
> > > >>>>>>>>>>>>>> [2015-01-24 10:15:50,801] INFO Opening socket connection
> > to
> > > >>>>>>>>>>>>>> server
> > > >>>>>>>>>>>>>> localhost/127.0.0.1:2181. Will not attempt to
> > authenticate
> > > >>>>>>>>>>>>>> using
> > > >>>>>>>>>>>>>> SASL
> > > >>>>>>>>>>>>>> (unknown error) (org.apache.zookeeper.ClientCnxn)
> > > >>>>>>>>>>>>>> [2015-01-24 10:15:50,802] WARN Session 0x14b1a413680
> > for
> > > >>>>>>>>>>>>>> server
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> null,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> unexpected error, closing socket connection and attempting
> > > >>>>>>>>>>>> reconnect
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> (org.apache.zookeeper.ClientCnxn)
> > > >>>>>>>>>>>>>> java.net.ConnectException: Connection refused
> > > >>>>>>>>>>>>>> at
> > sun.nio.ch.SocketChannelImpl.checkConnect(Native
> > > >>>>>>>>>>>>>> Method)
> > > >>>>>>>>>>>>>> at sun.nio.ch.SocketChannelImpl.finishConnect(
> > > >>>>>>>>>>>>>> SocketChannelImpl.java:739)
> > > >>>>>>>>>>>>>> at org.apache.zookeeper.ClientCnxnSocketNIO.
> > > >>>>>>>>>>>>>> doTransport(
> > > >>>>>>>>>>>>>> ClientCnxnSocketNIO.java:361)
> > > >>>>>>>>>>>>>> at
> > org.apache.zookeeper.ClientCnxn$SendThread.run(
> > > >>>>>>>>>>>>>> ClientCnxn.java:1081)
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> -Jaikiran
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>--
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>> Ewen
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> --
> > > >>>>>> -- Guozhang
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >
> > >
> > >
> > > --
> > > -- Guozhang
> >
>
--
Regards,
Ashish
://issues.apache.org/jira/browse/KAFKA-1664?focusedCommentId=14277439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14277439
How to run:
python dev-utils/test-patch.py --defect KAFKA-1664 --username
--password --run-tests --post-results
Thanks,
Ashish Singh
://issues.apache.org/jira/browse/KAFKA-1664?focusedCommentId=14277439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14277439
How to run:
python dev-utils/test-patch.py --defect KAFKA-1664 --username
--password --run-tests --post-results
Thanks,
Ashish Singh
893/#comment117568>
*matches* is basically list of patches attached to a JIRA, in the order of
dates they were attached. jira_get_attachment returns the latest patch attached
to the JIRA. I have tested this with a few JIRAs, like KAFKA-1634, and it works
fine.
- Ashish Singh
On Feb. 4, 2015,
ve 2 JIRA which is ok by
> > me.
*matches* is basically list of patches attached to a JIRA, in the order of
dates they were attached. jira_get_attachment returns the latest patch attached
to the JIRA. I have tested this with a few JIRAs, like KAFKA-1634, and it works
fine.
- Ashish
-
)
-
core/src/main/scala/kafka/admin/ConsumerGroupCommand.scala
89fa29a882ae1f2be512e1ae469631c02adeeddb
Diff: https://reviews.apache.org/r/28096/diff/
Testing
---
Ran ConsumerOffsetChecker with different combinations of --output.format and
--loop options.
Thanks,
Ashish Singh
/
Testing
---
Thanks,
Ashish Singh
: https://reviews.apache.org/r/31369/diff/
Testing
---
Thanks,
Ashish Singh
core/src/test/scala/unit/kafka/zk/ZKPathTest.scala PRE-CREATION
Diff: https://reviews.apache.org/r/28108/diff/
Testing
---
Tested with and without the fix.
Thanks,
Ashish Singh
examples/src/main/java/kafka/examples/Producer.java
96e98933148d07564c1b30ba8e805e2433c2adc8
Diff: https://reviews.apache.org/r/31369/diff/
Testing
---
Thanks,
Ashish Singh
examples/src/main/java/kafka/examples/Producer.java
96e98933148d07564c1b30ba8e805e2433c2adc8
Diff: https://reviews.apache.org/r/31369/diff/
Testing
---
Thanks,
Ashish Singh
m-1-0
> >> >>/
> >> >> >
> >> >> > We also published a detailed two-part guide on how you can put
> >>Kafka
> >> >>to
> >> >> use
> >> >> > in your organization -
> >> >> > http://blog.confluent.io/2015/02/25/stream-data-platform-1/
> >> >> >
> >> >> > And, there is a public mailing list where we would love to hear
> >>your
> >> >> > feedback: confluent-platf...@googlegroups.com
> >> >> >
> >> >> > Thanks,
> >> >> > Neha
> >> >> >
> >> >>
> >>
> >>
> >
> >
> >--
> >-- Guozhang
>
>
--
Regards,
Ashish
: https://reviews.apache.org/r/31369/diff/
Testing
---
Thanks,
Ashish Singh
he
> > key?
Done
> On Feb. 26, 2015, 10:27 p.m., Jun Rao wrote:
> > examples/src/main/java/kafka/examples/Producer.java, lines 81-88
> > <https://reviews.apache.org/r/31369/diff/4/?file=875220#file875220line81>
> >
> > It
and is making accepting patches very
> time-consuming.
> >
> > --
> > Thanks,
> > Neha
>
--
Regards,
Ashish
9897b2fa8f8261fe8ab6b62b45b9052adb07043f
Diff: https://reviews.apache.org/r/31711/diff/
Testing
---
Thanks,
Ashish Singh
examples/src/main/java/kafka/examples/SimpleConsumerDemo.java
0d66fe5f8819194c8624aed4a21105733c20cc8e
Diff: https://reviews.apache.org/r/31369/diff/
Testing
---
Thanks,
Ashish Singh
> On March 3, 2015, 5:42 a.m., Jun Rao wrote:
> >
Thanks for the review Jun! Addressed your concerns.
- Ashish
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31369/#re
> On Feb. 27, 2015, 7:29 p.m., Gwen Shapira wrote:
> > Thanks for the patch, Ashish. Its shaping up to be a very useful example.
> > Two comments:
> >
> > 1. I think the ser/de should be part of the example and not in "common",
> > I'
ing about the missing namespace. With current logic, if there is
an exception then namespace will be rechecked the next time as well. Let me
know if this does not make sense.
- Ashish
---
This is an automatically generated e-mail. To reply,
/test/scala/unit/kafka/zk/ZKPathTest.scala
9897b2fa8f8261fe8ab6b62b45b9052adb07043f
Diff: https://reviews.apache.org/r/31711/diff/
Testing
---
Thanks,
Ashish Singh
gt; > isNamespaceChecked is true, we will throw a ConfigException if the
> > namespace doesn't exist.
>
> Ashish Singh wrote:
> Not sure if that is a good idea. If we do that then there won't be an
> easy way to fix the situation. Even if someone creates that
/browse/KAFKA-2005
Repository: kafka
Description
---
KAFKA-2005: Generate html report for system tests
Diffs
-
system_test/system_test_runner.py 5078d4479fab71722751a28c3c8f5c0f61baadec
Diff: https://reviews.apache.org/r/31765/diff/
Testing
---
Thanks,
Ashish Singh
upgrade/bin/test-broker-upgrade.sh
<https://reviews.apache.org/r/30809/#comment125925>
Probably, extract out in a "upgrade" method for reusability and readability.
- Ashish Singh
On March 23, 2015, 6:54 p.m., Abhishek Nigam wrote:
>
> -
Hi Team,
I would like to subscribe to Kafka dev group
Thanks,
Ashish Singh
pose of
validation, right?
>
> -Harsha
>
> On Mon, Mar 7, 2016, at 04:33 PM, Ashish Singh wrote:
> > + Parth, Harsha
> >
> > On Mon, Mar 7, 2016 at 4:32 PM, Ashish Singh
> wrote:
> >
> > > Thanks Gwen.
> > >
> > > @Parth, @Harsha ping
@Magnus,
Does the latest suggestion sound OK to you. I am planning to update PR
based on latest suggestion.
On Mon, Mar 7, 2016 at 10:58 AM, Ashish Singh wrote:
>
>
> On Fri, Mar 4, 2016 at 5:46 PM, Jay Kreps wrote:
>
>> Hey Ashish,
>>
>> Both good points.
&g
might
> be
> > >> > outdated ( = cant be trusted)
> > >> > b) by the time the client connects to a given broker it might have
> > >> upgraded
> > >> >
> > >> > This means that a client (that is interested in protocol versioning)
l with a parsing exception, which is a bit better, but not much better.
> So, is it really worth doing? In the KIP call we had about this months ago,
> there was no consensus on this one from what I remember.
>
That is a good point! However, what about a client that wants to support
broker versions that do not provide broker version in metadata and broker
versions that provides version info in metadata. I think having this does
not cost us anything, but enables such clients to be smart.
>
> Ismael
>
--
Regards,
Ashish
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 ar
oker - we want to see an empty
> > packet and not a connection close.
> > Sending a broker version was deemed impractical IIRC.
> >
>
> OK, so this is a different case than the one Ashish described ("client that
> wants to support broker versions that do not pr
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 proto
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
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 P
1 - 100 of 1013 matches
Mail list logo
