9#file997819line88>
> >
> > Are we really mocking zkclient calls here?
Nope.. no zkclient calls being mocked here.
- Aditya
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/34554/#review90
hangeTest.scala
8a871cfaf6a534acd1def06a5ac95b5c985b024c
Diff: https://reviews.apache.org/r/34554/diff/
Testing
---
1. Added new testcases for new code.
2. Verified that both topic and client configs can be changed dynamically by
starting a local cluster
Thanks,
Aditya Auradkar
al cluster
Thanks,
Aditya Auradkar
il. To reply, visit:
https://reviews.apache.org/r/33378/#review91319
-------
On July 1, 2015, 2:44 a.m., Aditya Auradkar wrote:
>
> ---
> This is an automatically generated e-m
he old producer and
> > consumer as well. What do you think?
>
> Aditya Auradkar wrote:
> I think that sounds reasonable.. I initially decided against it in my
> patch because I thought of this as an incentive to upgrade. Any concerns if I
> submit a subsequent RB for thi
added
Thanks,
Aditya Auradkar
Test.scala
5717165f2344823fabe8f7cfafae4bb8af2d949a
core/src/test/scala/unit/kafka/server/ReplicaManagerTest.scala
00d59337a99ac135e8689bd1ecd928f7b1423d79
Diff: https://reviews.apache.org/r/33378/diff/
Testing
---
New tests added
Thanks,
Aditya Auradkar
his is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33378/#review91319
---
On July 13, 2015, 8:36 p.m., Aditya Auradkar wrote:
>
> -
his is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/34554/#review91038
-------
On July 8, 2015, 2:14 a.m., Aditya Auradkar wrote:
>
> ---
> This
and Jason Gustafson
kafka-2248; Use Apache Rat to enforce copyright headers; patched by Ewen
Cheslack-Postava; reviewed by Gwen Shapira, Joel Joshy and Jun Rao
kafka-2132; Move Log4J appender to a separate module; patched by Ashish Singh;
reviewed by Gwen Shapira, Aditya Auradkar and Jun Rao
nfigChangeTest.scala
8a871cfaf6a534acd1def06a5ac95b5c985b024c
Diff: https://reviews.apache.org/r/34554/diff/
Testing
---
1. Added new testcases for new code.
2. Verified that both topic and client configs can be changed dynamically by
starting a local cluster
Thanks,
Aditya Auradkar
ng a local cluster
Thanks,
Aditya Auradkar
uires KAFKA-2084 and 2136 to be committed first.
- Aditya
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/34554/#review91038
---
On July 14, 2015, 5:37 p.m., Aditya Auradkar wrote:
>
> ---
x27;t know about that util.
- Aditya
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/34554/#review92008
---
On July 14,
ynamically by
starting a local cluster
Thanks,
Aditya Auradkar
igs can be changed dynamically by
starting a local cluster
Thanks,
Aditya Auradkar
an be changed dynamically by
starting a local cluster
Thanks,
Aditya Auradkar
igs can be changed dynamically by
starting a local cluster
Thanks,
Aditya Auradkar
Did you setup your jira.ini?
On Tue, Jul 21, 2015 at 11:52 AM, Mayuresh Gharat <
gharatmayures...@gmail.com> wrote:
> Hi,
>
> I had to clean up existing kafka repo on my linux box and start with a
> fresh one.
>
> I followed the instructions here :
>
>
> https://cwiki.apache.org/confluence/displa
Hi,
Why not simply have as many partitions as the set of consumers you want to
round robin across?
Aditya
On Wed, Jul 22, 2015 at 2:37 PM, Ashish Singh wrote:
> Hey, don't you think that would be against the basic ordering guarantees
> Kafka provides?
>
> On Wed, Jul 22, 2015 at 2:14 PM, J A
uplicate the sensors we are adding in 2136 for the new
producer and consumer?
- Aditya Auradkar
On July 23, 2015, 7:12 a.m., Dong Lin wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://re
Hey everyone,
I was wondering if it is possible to standardize indentation across clients
and core. As an example, all the java code uses 4 spaces and the scala code
2. As we increasingly share code between clients and core, I think
consistency would be super useful.
Thoughts?
Aditya
I'm with Neha on this one. I don't have a strong preference on 2 vs 4 but I
do think that consistency is more important. It makes writing code a bit
easier especially since patches are increasingly likely to touch both Java
and Scala code and it's nice to not think about formatting certain files
di
and client configs can be changed dynamically by
starting a local cluster
Thanks,
Aditya Auradkar
igs can be changed dynamically by
starting a local cluster
Thanks,
Aditya Auradkar
Is there actually a use case where we need "log.retention.ms"? In most
cases, people would want to retain their logs for at least a few minutes
I'd think.
Aditya
On Fri, Jul 24, 2015 at 6:49 PM, Gwen Shapira wrote:
> Backward compatibility, I think.
>
> At least the "ms" one is fairly new, and
233)
<https://reviews.apache.org/r/36871/#comment147535>
consider closing this in a finally. A failing test can cause incorrect tear
down of the test
- Aditya Auradkar
On July 28, 2015, 12:56 a.m., Ashish Singh wrote:
>
> --
+1 on comparison with existing solutions. On a high level, it seems nice to
have a transform library inside Kafka.. a lot of the building blocks are
already there to build a stream processing framework. However the details
are tricky to get right I think this discussion will get a lot more
interest
Great discussion everyone!
One general comment on the sync/async API's on the new consumer. I think
the producer tackles sync vs async API's well. For API's that can either be
sync or async, can we simply return a future? That seems more elegant for
the API's that make sense either in both flavors
Personally, I prefer KafkaStreams just because it sounds nicer. For the
reasons identified above, KafkaProcessor or KProcessor is more apt but
sounds less catchy (IMO). I also think we should prefix with Kafka (rather
than K) because we will then have 3 clients: KafkaProducer, KafkaConsumer
and Kaf
t:
https://reviews.apache.org/r/33049/#review93991
-------
On June 30, 2015, 12:54 a.m., Aditya Auradkar wrote:
>
> ---
> This is an automatically generated e-
matically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33049/#review93965
-------
On June 30, 2015, 12:54 a.m., Aditya Auradkar wrote:
>
> ---
> This is an automatically gene
Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
it/kafka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
it/kafka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
btracting the windowSize (time unit) from a fraction
(metricValue/quota.bound()) gives the right delay.
I also added a comment for delayTime making sense for rates only.
- Aditya
---
This is an automatically generated e-
org/r/33049/#review94412
---
On Aug. 5, 2015, 2:08 a.m., Aditya Auradkar wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://review
Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
scala/unit/kafka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
. The last window is not complete.
> > So we need to take the current time into consideration.
> >
> > Finally, it seems that delayTime only makes sense for rates and not for
> > anything else. Perhaps we can at least add a comment.
>
> Aditya Auradkar wrot
Jun Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
unit/kafka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
ientId, value, callback) {
// add to delay queue
// pass in the computed throttle time to the callback.
}
If I do that, I dont need to pass the throttleTime to the responseCallback
in ReplicaManager
- Aditya Auradkar
On July 13, 2015, 8:36 p.m., Aditya Auradkar
e-mail. To reply, visit:
https://reviews.apache.org/r/33049/#review94412
---
On Aug. 10, 2015, 8:49 p.m., Aditya Auradkar wrote:
>
> ---
> This is an automatically gen
. The last window is not complete.
> > So we need to take the current time into consideration.
> >
> > Finally, it seems that delayTime only makes sense for rates and not for
> > anything else. Perhaps we can at least add a comment.
>
> Aditya Auradkar wrot
Jun Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
unit/kafka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
e all at once after
KAFKA-2084 is committed because I will need to rebase after that.
- Aditya Auradkar
On July 13, 2015, 8:36 p.m., Aditya Auradkar wrote:
>
> ---
> This is an automatically generated e-mail. To reply,
Bump. Anyone else have an opinion?
Neha/Jay - You've made your thoughts clear. Any thoughts on how/if we make
any changes?
Thanks,
Aditya
On Fri, Jul 24, 2015 at 10:32 AM, Aditya Auradkar
wrote:
> I'm with Neha on this one. I don't have a strong preference on 2 vs 4 but
an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33049/#review95035
-------
On Aug. 11, 2015, 4:58 a.m., Aditya Auradkar wrote:
>
> ---
> This is
Jun Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33049/#review95033
---
On Aug. 11, 2015, 4:58 a.m., Aditya Auradkar wrote:
>
> -
unit/kafka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
Jun Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
unit/kafka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
Jun Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
unit/kafka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
Jun Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
fka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
Jun Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
fka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33049/#review95369
---
On Aug. 14, 2015, 2:09 a.m., Aditya Auradkar wrote:
>
> ---
Jun Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
fka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
fka/server/ThrottledResponseExpirationTest.scala
PRE-CREATION
Diff: https://reviews.apache.org/r/33049/diff/
Testing
---
Thanks,
Aditya Auradkar
Jun Rao.
Bugs: KAFKA-2084
https://issues.apache.org/jira/browse/KAFKA-2084
Repository: kafka
Description (updated)
---
Signed-off-by: Aditya Auradkar
Addressing Joel's comments
Minor imports changes
Added testcase to verify that replication traffic is not throttled
Tmp c
KafkaMetrics passed in
> > has a measurable that's an instance of Rate. If so, we will compute the
> > delay for rate (the window should be elapsedCurrent and elapsedPrior as
> > computed in Rate.measure()).
>
> Aditya Auradkar wrote:
> Rate/Measurable stat doe
CommitRequest as
> > an example.
Good point.
- Aditya
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33378/#review94167
-----
-2248; Use Apache Rat to enforce copyright headers; patched by Ewen
Cheslack-Postava; reviewed by Gwen Shapira, Joel Joshy and Jun Rao
kafka-2132; Move Log4J appender to a separate module; patched by Ashish Singh;
reviewed by Gwen Shapira, Aditya Auradkar and Jun Rao
KAFKA-2314: proper
iews.apache.org/r/33378/diff/
Testing
---
New tests added
Thanks,
Aditya Auradkar
kafka/server/ThrottledResponseExpirationTest.scala
14a7f4538041d557c190127e3d5f85edf2a0e7c1
Diff: https://reviews.apache.org/r/33378/diff/
Testing
---
New tests added
Thanks,
Aditya Auradkar
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33049/#review95793
---
On Aug. 15, 2015, 12:43 a.m., Aditya Auradkar wrote:
>
> -
009
---
On Aug. 18, 2015, 8:24 p.m., Aditya Auradkar wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33378/
> ---
4f1460c1a52bf52
Diff: https://reviews.apache.org/r/33378/diff/
Testing
---
New tests added
Thanks,
Aditya Auradkar
kafka/server/ThrottledResponseExpirationTest.scala
c4b5803917e700965677d53624f1460c1a52bf52
Diff: https://reviews.apache.org/r/33378/diff/
Testing
---
New tests added
Thanks,
Aditya Auradkar
ationTest.scala
c4b5803917e700965677d53624f1460c1a52bf52
Diff: https://reviews.apache.org/r/33378/diff/
Testing
---
New tests added
Thanks,
Aditya Auradkar
kafka/server/ThrottledResponseExpirationTest.scala
c4b5803917e700965677d53624f1460c1a52bf52
Diff: https://reviews.apache.org/r/33378/diff/
Testing
---
New tests added
Thanks,
Aditya Auradkar
igrates the broker to use these schemas?
- Aditya
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33378/#review96100
---
ly need a versionId as well (as is done in the Scala
> > response) - i.e., when we move the broker over to use these protocol
> > schemas.
>
> Aditya Auradkar wrote:
> Makes sense. Do you want me to tackle this in this patch or should it be
> tackled in the patch that
it/kafka/server/ThrottledResponseExpirationTest.scala
c4b5803917e700965677d53624f1460c1a52bf52
Diff: https://reviews.apache.org/r/33378/diff/
Testing
---
New tests added
Thanks,
Aditya Auradkar
kafka/server/ThrottledResponseExpirationTest.scala
c4b5803917e700965677d53624f1460c1a52bf52
Diff: https://reviews.apache.org/r/33378/diff/
Testing
---
New tests added
Thanks,
Aditya Auradkar
topicExists simply reads ZK, so yes. createTopic should also be fine unless
you try to create the same topic concurrently. AdminUtils itself does not
maintain any state, just some static util functions.
On Mon, Aug 31, 2015 at 3:00 PM, Sivananda Reddys Thummala Abbigari <
sthumm...@salesforce.com>
Typically to discuss anything listed here or other important changes:
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
On Tue, Sep 1, 2015 at 1:28 AM, jinxing wrote:
> Can I know what is KIP meeting?
>
>
>
>
>
>
> At 2015-09-01 12:30:18, "Jun Rao" wrote:
> >Since th
Congrats Jason.
On Fri, Sep 9, 2016 at 5:30 AM, Michael Noll wrote:
> My compliments, Jason -- well deserved! :-)
>
> -Michael
>
>
>
> On Wed, Sep 7, 2016 at 6:49 PM, Grant Henke wrote:
>
> > Congratulations and thank you for all of your contributions to Apache
> > Kafka Jason!
> >
> > On Wed,
Correct.
Aditya
On Tue, Sep 1, 2015 at 9:47 AM, Jaikiran Pai
wrote:
> On Tuesday 01 September 2015 09:51 AM, Aditya Auradkar wrote:
>
>> createTopic should also be fine unless you try to create the same topic
>> concurrently.
>>
>
> Just to be clear - that would
I thought this would be of interest:
https://developer.zendesk.com/blog/introducing-maxwell-a-mysql-to-kafka-binlog-processor
A copycat connector that parses MySQL binlogs would be rather useful I
think. Streaming connectors using jdbc are tricky to implement because they
rely on an indexed timest
Hi Gwen,
I certainly think 0.9.0 is better than 0.8.3.
As regards semantic versioning, do we have a plan for a 1.0 release? IIUC,
compatibility rules don't really apply for pre-1.0 stuff. I'd argue that
Kafka already qualifies for 1.x.
Aditya
On Tue, Sep 8, 2015 at 10:26 AM, Gwen Shapira wrote:
+1 on 0.9
On Tue, Sep 8, 2015 at 12:29 PM, Edward Ribeiro
wrote:
> +1 on 0.9.0
>
> On Tue, Sep 8, 2015 at 4:07 PM, Ashish Singh wrote:
>
> > +1 on 0.9.0
> >
> > On Tue, Sep 8, 2015 at 12:00 PM, Gwen Shapira wrote:
> >
> > > I propose a simple rename: s/0.8.3/0.9.0/
> > >
> > > No change of sco
Congrats Sriharsha! Great work.. especially on SSL.
On Mon, Sep 21, 2015 at 10:31 PM, Prabhjot Bharaj
wrote:
> Congratulations. It's inspiring for newbies like me
>
> Regards,
> Prabhjot
> On Sep 22, 2015 10:30 AM, "Ashish Singh" wrote:
>
> > Congrats Harsha!
> >
> > On Monday, September 21, 20
+1
On Wed, Sep 23, 2015 at 8:03 PM, Neha Narkhede wrote:
> +1
>
> On Wed, Sep 23, 2015 at 6:21 PM, Todd Palino wrote:
>
> > +1000
> >
> > !
> >
> > -Todd
> >
> > On Wednesday, September 23, 2015, Jiangjie Qin >
> > wrote:
> >
> > > Hi,
> > >
> > > Thanks a lot for the reviews and feedback on K
Basically, 0.8.3 has been renamed to 0.9.0. The plan is to include security
in the 0.9 release which should happen once all the blocker bugs have been
resolved and testing is complete (committers can provide more accurate
timelines).
On Fri, Sep 25, 2015 at 10:35 AM, Whitney, Adam
wrote:
> Hello
Thanks for starting this KIP Allen.
I agree with Gwen that having a RackLocator class that is pluggable seems
to be too complex. The KIP refers to potentially non-ZK storage for the
rack info which I don't think is necessary.
Perhaps we can persist this info in zk under /brokers/ids/
similar to o
ion about the physical location
> > of servers. I don't relish the idea of having to maintain data in
> multiple
> > places.
> >
> > -Todd
> >
> > On Mon, Sep 28, 2015 at 4:48 PM, Aditya Auradkar <
> > aaurad...@linkedin.com.invalid> wrote:
Hey everyone,
We were recently discussing a small logging improvement for Kafka.
Basically, add a request log for queries that took longer than a certain
configurable time to execute. This can be quite useful for debugging
purposes, in fact it would have proven handy while investigating a recent
i
t; >> > > >
> >> > > > On Thu, Oct 8, 2015 at 9:23 AM, Allen Wang
> >> > wrote:
> >> > > >
> >> > > > > I attended Tuesday's KIP hangout but this KIP was not discussed
> >> due
> >> > to
&
pture detailed timing of a random sample of the requests and log it
> > (i.e sample metrics rather than avgs). Note that clients that send more
> > requests and longer requests are more likely to get sampled. I've found
> > this super useful in the past.
> >
> > Gw
Hi Abhishek -
Perhaps it would help if you explained the motivation behind your proposal.
I know there was a bunch of discussion on KAFKA-1778, can you summarize?
Currently, I'd agree with Neha and Jay that there isn't really a strong
reason to pin the controller to a given broker or restricted to
+1 (non-binding).
On Wed, Oct 21, 2015 at 3:57 PM, Ismael Juma wrote:
> +1 (non-binding)
>
> On Wed, Oct 21, 2015 at 4:17 PM, 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
> We allow dynamic topic creation with incomplete broker-rack mapping and
> fail fast in command line. Another option is to let user determine the
> behavior for command line. For example, by default fail fast in command
> line but allow incomplete broker-rack mapping if
201 - 300 of 463 matches
Mail list logo
