[jira] [Updated] (KAFKA-1915) Integrate checkstyle for java code

[ https://issues.apache.org/jira/browse/KAFKA-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ewen Cheslack-Postava updated KAFKA-1915: - Resolution: Fixed Reviewer: Joel Koshy Status: Resolved (was: Patch

Re: [KIP-DISCUSSION] KIP-13 Quotas

wait. we create one kafka producer for each cluster. each cluster can have many topics. if producer buffer got filled up due to delayed response for one throttled topic, won't that penalize other topics unfairly? it seems to me that broker should just return error without delay. sorry that I am ch

Re: [KIP-DISCUSSION] KIP-13 Quotas

I think I can answer my own question. delayed response will cause the producer buffer to be full, which then result in either thread blocking or message drop. On Mon, Mar 16, 2015 at 11:24 PM, Steven Wu wrote: > please correct me if I am missing sth here. I am not understanding how > would throt

Re: [KIP-DISCUSSION] KIP-13 Quotas

please correct me if I am missing sth here. I am not understanding how would throttle work without cooperation/back-off from producer. new Java producer supports non-blocking API. why would delayed response be able to slow down producer? producer will continue to fire async sends. On Mon, Mar 16,

Re: [KIP-DISCUSSION] KIP-13 Quotas

I think we are really discussing two separate issues here: 1. Whether we should a) append-then-block-then-returnOKButThrottled or b) block-then-returnFailDuetoThrottled for quota actions on produce requests. Both these approaches assume some kind of well-behaveness of the clients: option a) assum

Re: [KIP-DISCUSSION] KIP-13 Quotas

You are right, shoe-horning status into an error field is a bad idea. While many projects use a single "status" field to indicate different error and non-error states, it doesn't seem like a good fit for the current Kafka implementation. Do you think that adding a "status" field to our protocol is

Re: [DISCUSSION] KIP-15 close(timeout) for producer

Yeah in this sense the sender thread will not exist immediately in the close(0) call, but will only terminate after the current response batch has been processed, as will the producer instance itself. There is a reason for this though: for a clean shutdown the caller thread has to wait for the sen

Re: [KIP-DISCUSSION] KIP-13 Quotas

Agreed that trying to shoehorn non-error codes into the error field is a bad idea. It makes it *way* too easy to write code that looks (and should be) correct but is actually incorrect. If necessary, I think it's much better to to spend a couple of extra bytes to encode that information separately

Re: [KIP-DISCUSSION] KIP-13 Quotas

We discussed an error code for rate-limiting (which I think made sense), isn't it a similar case? On Mon, Mar 16, 2015 at 10:10 PM, Jay Kreps wrote: > My concern is that as soon as you start encoding non-error response > information into error codes the next question is what to do if two such > c

Re: [KIP-DISCUSSION] KIP-13 Quotas

My concern is that as soon as you start encoding non-error response information into error codes the next question is what to do if two such codes apply (i.e. you have a replica down and the response is quota'd). I think I am trying to argue that error should mean "why we failed your request", for

Re: [KIP-DISCUSSION] KIP-13 Quotas

I think its not too late to reserve a set of error codes (200-299?) for "non-error" codes. It won't be backward compatible (i.e. clients that currently do "else throw" will throw on non-errors), but perhaps its worthwhile. On Mon, Mar 16, 2015 at 9:42 PM, Jay Kreps wrote: > Hey Jun, > > I'd real

Re: [KIP-DISCUSSION] KIP-13 Quotas

Hey Jun, I'd really really really like to avoid that. Having just spent a bunch of time on the clients, using the error codes to encode other information about the response is super dangerous. The error handling is one of the hardest parts of the client (Guozhang chime in here). Generally the err

Re: [DISCUSSION] KIP-15 close(timeout) for producer

Hmm, does that mean that after close(0), the sender thread is not necessary gone? Normally, after closing an entity, we expect all internal threads associated with the entity are shut down completely. Thanks, Jun On Mon, Mar 16, 2015 at 3:18 PM, Jiangjie Qin wrote: > Hi Jun, > > Close(0) will

Re: [DISCUSS] KIP-6 - New reassignment partition logic for re-balancing

Hi, Joe, A couple of comments. 1. When creating a new topic, our replica assignment algorithm tries to achieve a few things: (a) all replicas are spread evenly across brokers; (b) the preferred replica (first replica in the assigned replica list) of all partitions are spread evenly across brokers

[jira] [Resolved] (KAFKA-2023) git clone kafka repository requires https

[ https://issues.apache.org/jira/browse/KAFKA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Stein resolved KAFKA-2023. -- Resolution: Fixed pushed change to doc > git clone kafka repository requires https > --

[jira] [Updated] (KAFKA-2023) git clone kafka repository requires https

[ https://issues.apache.org/jira/browse/KAFKA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Stein updated KAFKA-2023: - Reviewer: Gwen Shapira > git clone kafka repository requires https > -

[jira] [Assigned] (KAFKA-2023) git clone kafka repository requires https

[ https://issues.apache.org/jira/browse/KAFKA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Stein reassigned KAFKA-2023: Assignee: Anatoly Fayngelerin > git clone kafka repository requires https > ---

[jira] [Commented] (KAFKA-2023) git clone kafka repository requires https

[ https://issues.apache.org/jira/browse/KAFKA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364412#comment-14364412 ] Gwen Shapira commented on KAFKA-2023: - If its the default on a popular OS, I'd update

[jira] [Commented] (KAFKA-2023) git clone kafka repository requires https

[ https://issues.apache.org/jira/browse/KAFKA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364404#comment-14364404 ] Anatoli Fomenko commented on KAFKA-2023: Concur: the problem persists with git 1.7

[jira] [Commented] (KAFKA-1646) Improve consumer read performance for Windows

[ https://issues.apache.org/jira/browse/KAFKA-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364344#comment-14364344 ] Sriharsha Chintalapani commented on KAFKA-1646: --- [~waldenchen] Its looks lik

Re: Review Request 29091: Improve 1646 fix by reduce check if Os.IsWindows

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/29091/#review76688 --- core/src/main/scala/kafka/utils/Utils.scala

[jira] [Created] (KAFKA-2024) Cleaner can generate unindexable log segments

Gian Merlino created KAFKA-2024: --- Summary: Cleaner can generate unindexable log segments Key: KAFKA-2024 URL: https://issues.apache.org/jira/browse/KAFKA-2024 Project: Kafka Issue Type: Bug

RE: [KIP-DISCUSSION] KIP-13 Quotas

In Jay's approach, a client will simply experience a delay in receiving a response. The primary benefit is that there are no concerns regarding data-loss because the data has already been appended. Retries are also a non-issue since there is no need for them. However, the drawback to append and

[jira] [Commented] (KAFKA-2023) git clone kafka repository requires https

[ https://issues.apache.org/jira/browse/KAFKA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364263#comment-14364263 ] Joe Stein commented on KAFKA-2023: -- looks like maybe the issue is the version of git, i t

Re: [KIP-DISCUSSION] KIP-13 Quotas

It's probably useful for a client to know whether its requests are throttled or not (e.g., for monitoring and alerting). From that perspective, option B (delay the requests and return an error) seems better. Thanks, Jun On Wed, Mar 4, 2015 at 3:51 PM, Aditya Auradkar < aaurad...@linkedin.com.inv

[jira] [Commented] (KAFKA-2023) git clone kafka repository requires https

[ https://issues.apache.org/jira/browse/KAFKA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364205#comment-14364205 ] Anatoli Fomenko commented on KAFKA-2023: Works for me on MacOS but not on one Cent

[jira] [Updated] (KAFKA-2023) git clone kafka repository requires https

[ https://issues.apache.org/jira/browse/KAFKA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anatoli Fomenko updated KAFKA-2023: --- Attachment: KAFKA-2023.patch Please review the patch. Thank you. > git clone kafka repositor

[jira] [Commented] (KAFKA-2023) git clone kafka repository requires https

[ https://issues.apache.org/jira/browse/KAFKA-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364184#comment-14364184 ] Joe Stein commented on KAFKA-2023: -- works ok for me on ubuntu and redhat on two different

[jira] [Created] (KAFKA-2023) git clone kafka repository requires https

Anatoli Fomenko created KAFKA-2023: -- Summary: git clone kafka repository requires https Key: KAFKA-2023 URL: https://issues.apache.org/jira/browse/KAFKA-2023 Project: Kafka Issue Type: Bug

[jira] [Commented] (KAFKA-1688) Add authorization interface and naive implementation

[ https://issues.apache.org/jira/browse/KAFKA-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364166#comment-14364166 ] Parth Brahmbhatt commented on KAFKA-1688: - [~jkreps][~junrao] Not sure if you guys

Re: Review Request 31742: Patch for KAFKA-527

On March 13, 2015, 11:43 p.m., Yasuhiro Matsuda wrote: > > The inheritance of MessageWriter from BufferingOutputStream is a bit > > confusing, since it will always use itself in the writePayload function > > parameter. > > > > I feel it is more clear to read the code if we just let MessageWri

Re: Review Request 31967: Patch for KAFKA-1546

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31967/#review76641 --- lgtm overall. Minor comments below. core/src/test/scala/unit/kafka

[jira] [Updated] (KAFKA-527) Compression support does numerous byte copies

[ https://issues.apache.org/jira/browse/KAFKA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yasuhiro Matsuda updated KAFKA-527: --- Attachment: KAFKA-527_2015-03-16_15:19:29.patch > Compression support does numerous byte copies

Re: Review Request 31742: Patch for KAFKA-527

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31742/ --- (Updated March 16, 2015, 10:19 p.m.) Review request for kafka. Bugs: KAFKA-52

[jira] [Commented] (KAFKA-527) Compression support does numerous byte copies

[ https://issues.apache.org/jira/browse/KAFKA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364085#comment-14364085 ] Yasuhiro Matsuda commented on KAFKA-527: Updated reviewboard https://reviews.apache

Re: [DISCUSSION] KIP-15 close(timeout) for producer

Hi Jun, Close(0) will set two flags in sender. Running=false and a newly added forceClose=true. It will also set accumulator.closed=true so no further producer.send() will succeed. The sender thread will finish executing all the callbacks in current batch of responses, then it will see the forceCl

Re: [DISCUSSION] KIP-15 close(timeout) for producer

How does close(0) work if it's called from the sender thread? If close(0) needs to wait for the sender thread to join, wouldn't this cause a deadlock? Thanks, Jun On Mon, Mar 16, 2015 at 2:26 PM, Jiangjie Qin wrote: > Thanks Guozhang. It wouldn’t be as thoroughly considered without > discussin

Re: Review Request 31893: Patch for KAFKA-2013

> On March 16, 2015, 5:17 p.m., Jun Rao wrote: > > core/src/test/scala/other/kafka/TestPurgatoryPerformance.scala, line 193 > > > > > > Is there a particular reason that we need to overwrite isCompleted()? > > Typical

[jira] [Updated] (KAFKA-2013) benchmark test for the purgatory

[ https://issues.apache.org/jira/browse/KAFKA-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yasuhiro Matsuda updated KAFKA-2013: Attachment: KAFKA-2013_2015-03-16_14:39:07.patch > benchmark test for the purgatory > --

[jira] [Commented] (KAFKA-2013) benchmark test for the purgatory

[ https://issues.apache.org/jira/browse/KAFKA-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364008#comment-14364008 ] Yasuhiro Matsuda commented on KAFKA-2013: - Updated reviewboard https://reviews.apa

Re: Review Request 31893: Patch for KAFKA-2013

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31893/ --- (Updated March 16, 2015, 9:39 p.m.) Review request for kafka. Bugs: KAFKA-201

Re: Review Request 31958: Patch for KAFKA-1684

> On March 16, 2015, 9:24 p.m., Michael Herstine wrote: > > core/src/main/scala/kafka/network/SocketServer.scala, line 318 > > > > > > `{want,needs}ClientAuth` can be tricky-- check the javadoc for > > `SSLEngine.setW

Re: Review Request 31958: Patch for KAFKA-1684

> On March 16, 2015, 9:24 p.m., Michael Herstine wrote: > > core/src/main/scala/kafka/network/ssl/SSLChannel.scala, line 137 > > > > > > Suppose SSLEngine has written the current message (via `wrap`) to > > `netOutBuf

Re: [DISCUSSION] KIP-15 close(timeout) for producer

Thanks Guozhang. It wouldn’t be as thoroughly considered without discussing with you :) Jiangjie (Becket) Qin On 3/16/15, 1:07 PM, "Guozhang Wang" wrote: >Thanks Jiangjie, > >After talking to you offline on this, I have been convinced and changed my >preference to blocking. The immediate shutdo

Re: Review Request 31958: Patch for KAFKA-1684

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31958/#review76640 --- core/src/main/scala/kafka/network/SocketServer.scala

[jira] [Updated] (KAFKA-2013) benchmark test for the purgatory

[ https://issues.apache.org/jira/browse/KAFKA-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yasuhiro Matsuda updated KAFKA-2013: Attachment: KAFKA-2013_2015-03-16_14:13:20.patch > benchmark test for the purgatory > --

Re: Review Request 31893: Patch for KAFKA-2013

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31893/ --- (Updated March 16, 2015, 9:13 p.m.) Review request for kafka. Bugs: KAFKA-201

[jira] [Commented] (KAFKA-2013) benchmark test for the purgatory

[ https://issues.apache.org/jira/browse/KAFKA-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363957#comment-14363957 ] Yasuhiro Matsuda commented on KAFKA-2013: - Updated reviewboard https://reviews.apa

Re: [DISCUSS] KIP-4 - Command line and centralized administrative operations

101. There may be a use case where you only want the topics to be created manually by admins. Currently, you can do that by disabling auto topic creation and issue topic creation from the TopicCommand. If we disable auto topic creation completely on the broker and don't have a way to distinguish be

Re: Review Request 31742: Patch for KAFKA-527

> On March 13, 2015, 11:43 p.m., Guozhang Wang wrote: > > core/src/main/scala/kafka/message/MessageWriter.scala, line 29 > > > > > > Add a check that codec should not be NoCompression. > > Yasuhiro Matsuda wrote: >

[jira] [Commented] (KAFKA-2013) benchmark test for the purgatory

[ https://issues.apache.org/jira/browse/KAFKA-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363843#comment-14363843 ] Yasuhiro Matsuda commented on KAFKA-2013: - Updated reviewboard https://reviews.apa

[jira] [Updated] (KAFKA-2013) benchmark test for the purgatory

[ https://issues.apache.org/jira/browse/KAFKA-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yasuhiro Matsuda updated KAFKA-2013: Attachment: KAFKA-2013_2015-03-16_13:23:38.patch > benchmark test for the purgatory > --

Re: Review Request 31893: Patch for KAFKA-2013

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31893/ --- (Updated March 16, 2015, 8:23 p.m.) Review request for kafka. Bugs: KAFKA-201

Re: Review Request 31893: Patch for KAFKA-2013

> On March 16, 2015, 5:17 p.m., Jun Rao wrote: > > core/src/test/scala/other/kafka/TestPurgatoryPerformance.scala, line 193 > > > > > > Is there a particular reason that we need to overwrite isCompleted()? > > Typical

Re: [DISCUSSION] KIP-15 close(timeout) for producer

Thanks Jiangjie, After talking to you offline on this, I have been convinced and changed my preference to blocking. The immediate shutdown approach does have some unsafeness in some cases. Guozhang On Mon, Mar 16, 2015 at 11:50 AM, Jiangjie Qin wrote: > It looks that the problem we want to sol

[jira] [Created] (KAFKA-2022) simpleconsumer.fetch(req) throws a java.nio.channels.ClosedChannelException: null exception when the original leader fails instead of being trapped in the fetchResponse a

Muqeet Mohammed Ali created KAFKA-2022: -- Summary: simpleconsumer.fetch(req) throws a java.nio.channels.ClosedChannelException: null exception when the original leader fails instead of being trapped in the fetchResponse api while consuming m

Re: Review Request 32061: WIP for KAFKA-2015 plus some minor fixes in new consumer

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/32061/#review76630 --- Ship it! Ship It! - Onur Karaman On March 13, 2015, 10:26 p.m.,

Re: [DISCUSSION] KIP-15 close(timeout) for producer

It looks that the problem we want to solve and the purpose we want to achieve is: If user uses close() in callback, we want to let user be aware that they should use close(0) instead of close() in the callback. We have agreed that we will have an error log to inform user about this mis-usage. The

Re: Review Request 31742: Patch for KAFKA-527

> On March 13, 2015, 11:43 p.m., Guozhang Wang wrote: > > core/src/main/scala/kafka/message/MessageWriter.scala, line 29 > > > > > > Add a check that codec should not be NoCompression. Why the codec should not be NoCom

[jira] [Commented] (KAFKA-2020) I expect ReplicaNotAvailableException to have proper Javadocs

[ https://issues.apache.org/jira/browse/KAFKA-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363678#comment-14363678 ] Jun Rao commented on KAFKA-2020: The following is the protocol for TopicMetadataResponse.

Re: Review Request 31967: Patch for KAFKA-1546

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31967/ --- (Updated March 16, 2015, 6:32 p.m.) Review request for kafka. Bugs: KAFKA-154

Re: Review Request 31967: Patch for KAFKA-1546

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31967/ --- (Updated March 16, 2015, 6:31 p.m.) Review request for kafka. Bugs: KAFKA-154

[jira] [Updated] (KAFKA-1546) Automate replica lag tuning

[ https://issues.apache.org/jira/browse/KAFKA-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aditya A Auradkar updated KAFKA-1546: - Attachment: KAFKA-1546_2015-03-16_11:31:39.patch > Automate replica lag tuning > -

[jira] [Commented] (KAFKA-1546) Automate replica lag tuning

[ https://issues.apache.org/jira/browse/KAFKA-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363672#comment-14363672 ] Aditya A Auradkar commented on KAFKA-1546: -- Updated reviewboard https://reviews.a

[jira] [Commented] (KAFKA-2019) RoundRobinAssignor clusters by consumer

[ https://issues.apache.org/jira/browse/KAFKA-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363625#comment-14363625 ] Joseph Holsten commented on KAFKA-2019: --- [~becket_qin] could you provide an example

[jira] [Comment Edited] (KAFKA-2019) RoundRobinAssignor clusters by consumer

[ https://issues.apache.org/jira/browse/KAFKA-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363625#comment-14363625 ] Joseph Holsten edited comment on KAFKA-2019 at 3/16/15 6:10 PM:

[jira] [Comment Edited] (KAFKA-2019) RoundRobinAssignor clusters by consumer

[ https://issues.apache.org/jira/browse/KAFKA-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363625#comment-14363625 ] Joseph Holsten edited comment on KAFKA-2019 at 3/16/15 6:09 PM:

Re: [DISCUSS] KIP-4 - Command line and centralized administrative operations

Jun, Answering your questions: 101. If I understand you correctly, you are saying future producer versions (which will be ported to TMR_V1) won't be able to automatically create topic (if we unconditionally remove topic creation from there). But we need to this preserve logic. Ok, about your prop

Re: Review Request 31967: Patch for KAFKA-1546

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31967/#review76585 --- core/src/main/scala/kafka/cluster/Partition.scala

Re: Review Request 31967: Patch for KAFKA-1546

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31967/#review76571 --- Working on the remaining comments. Shall update the RB core/src/ma

Re: Review Request 31893: Patch for KAFKA-2013

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31893/#review76566 --- Thanks for the patch. A few comments. core/src/test/scala/other/ka

Re: [DISCUSSION] KIP-15 close(timeout) for producer

HI Jiangjie, As far as I understand calling close() in the ioThread is not common, as it may only trigger when we saw some non-retriable error. Hence when user run their program it is unlikely that close() will be triggered and problem will be detected. So it seems to me that from the error detect

Re: [DISCUSSION] KIP-15 close(timeout) for producer

It seems there are two options we can choose from when close() is called from sender thread (callback): 1. Log an error and close the producer using close(-1) 2. Log an error and block. (Throwing an exception will not work because we catch all the exception thrown from user callback. It will just l

[jira] [Commented] (KAFKA-1809) Refactor brokers to allow listening on multiple ports and IPs

[ https://issues.apache.org/jira/browse/KAFKA-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363465#comment-14363465 ] Gwen Shapira commented on KAFKA-1809: - Updated reviewboard https://reviews.apache.org/

Re: [DISCUSSION] KIP-15 close(timeout) for producer

Agree. Since throwing exception when close() is called in callback won’t work because we are catching all the exceptions from callback, blocking might be the only option we have here. Jiangjie (Becket) Qin On 3/15/15, 11:56 AM, "Jay Kreps" wrote: >Cool. > >I think blocking is good or alternatel

[jira] [Updated] (KAFKA-1809) Refactor brokers to allow listening on multiple ports and IPs

[ https://issues.apache.org/jira/browse/KAFKA-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gwen Shapira updated KAFKA-1809: Attachment: KAFKA-1809_2015-03-16_09:40:49.patch > Refactor brokers to allow listening on multiple p

Re: Review Request 28769: Patch for KAFKA-1809

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28769/ --- (Updated March 16, 2015, 4:41 p.m.) Review request for kafka. Bugs: KAFKA-180

Re: Question about concurrency during Log config change

Jay, Thanks for quick response. Yes, this might be not that harmful for users, I'm not sure about that. But it definitely looks like data race. Your solution is simple and should work, hard to tell promptly when it's about concurrency. Initially I was looking through this code to understand wheth

[jira] [Updated] (KAFKA-1928) Move kafka.network over to using the network classes in org.apache.kafka.common.network

[ https://issues.apache.org/jira/browse/KAFKA-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede updated KAFKA-1928: - Component/s: security > Move kafka.network over to using the network classes in > org.apache.kafk

[jira] [Updated] (KAFKA-1928) Move kafka.network over to using the network classes in org.apache.kafka.common.network

[ https://issues.apache.org/jira/browse/KAFKA-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede updated KAFKA-1928: - Issue Type: Sub-task (was: Improvement) Parent: KAFKA-1682 > Move kafka.network over to u

[jira] [Commented] (KAFKA-1809) Refactor brokers to allow listening on multiple ports and IPs

[ https://issues.apache.org/jira/browse/KAFKA-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363429#comment-14363429 ] Gwen Shapira commented on KAFKA-1809: - [~junrao]: 1. Addressed all sub-points 2. I th

[jira] [Commented] (KAFKA-1809) Refactor brokers to allow listening on multiple ports and IPs

[ https://issues.apache.org/jira/browse/KAFKA-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363399#comment-14363399 ] Gwen Shapira commented on KAFKA-1809: - Updated reviewboard https://reviews.apache.org/

Re: Review Request 28769: Patch for KAFKA-1809

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28769/ --- (Updated March 16, 2015, 4:02 p.m.) Review request for kafka. Bugs: KAFKA-180

[jira] [Updated] (KAFKA-1809) Refactor brokers to allow listening on multiple ports and IPs

[ https://issues.apache.org/jira/browse/KAFKA-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gwen Shapira updated KAFKA-1809: Attachment: KAFKA-1809_2015-03-16_09:02:18.patch > Refactor brokers to allow listening on multiple p

[jira] [Assigned] (KAFKA-2021) Consolidate test classes for KafkaConfig

[ https://issues.apache.org/jira/browse/KAFKA-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Biletskyi reassigned KAFKA-2021: --- Assignee: Andrii Biletskyi > Consolidate test classes for KafkaConfig > -

Re: Question about concurrency during Log config change

You are correct. Each read will be a valid value but there is no guarantee that subsequent reads will read from the same config. I don't think that is a problem, do you? If we want to strengthen the guarantee we can grab the config once in the method val config = log.config and then do however m

Question about concurrency during Log config change

Hi all, I was looking through the code related to "dynamic Log config change" feature and noticed the way we deal with concurrency there. I have a question about it. The Log class holds volatile LogConfig property, almost all methods in Log.scala are synchronized on private lock object. But the c

[jira] [Commented] (KAFKA-1994) Evaluate performance effect of chroot check on Topic creation

[ https://issues.apache.org/jira/browse/KAFKA-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363349#comment-14363349 ] Gwen Shapira commented on KAFKA-1994: - New patch looks good. [~singhashish], can you

Re: java.net.BindException: Address already in use

This is being tracked in KAFKA-1501. Typically, this won't happen on a dedicated machine. Thanks, Jun On Mon, Mar 16, 2015 at 5:02 AM, Tong Li wrote: > > Hi guys, when I ran test, I got a lot of these exceptions. I wonder if you > had similar problems running the tests and how resolved the iss

[jira] [Created] (KAFKA-2021) Consolidate test classes for KafkaConfig

Gwen Shapira created KAFKA-2021: --- Summary: Consolidate test classes for KafkaConfig Key: KAFKA-2021 URL: https://issues.apache.org/jira/browse/KAFKA-2021 Project: Kafka Issue Type: Task

[jira] [Commented] (KAFKA-1926) Replace kafka.utils.Utils with o.a.k.common.utils.Utils

[ https://issues.apache.org/jira/browse/KAFKA-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363164#comment-14363164 ] Tong Li commented on KAFKA-1926: @Jun Rao, awesome comments. I will be following the direc

[jira] [Commented] (KAFKA-1305) Controller can hang on controlled shutdown with auto leader balance enabled

[ https://issues.apache.org/jira/browse/KAFKA-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363129#comment-14363129 ] Dmitry Bugaychenko commented on KAFKA-1305: --- Even with a fast dedicated channel

java.net.BindException: Address already in use

Hi guys, when I ran test, I got a lot of these exceptions. I wonder if you had similar problems running the tests and how resolved the issue. Thanks. Tong Li OpenStack & Kafka Community Development Building 501/B205 liton...@us.ibm.com

[jira] [Commented] (KAFKA-1646) Improve consumer read performance for Windows

[ https://issues.apache.org/jira/browse/KAFKA-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363051#comment-14363051 ] Honghai Chen commented on KAFKA-1646: - Hey [~jkreps] Is it ok to add one configuration