[jira] [Commented] (KAFKA-4888) offset 449883 is invalid, cause: Record is corrupt (stored crc = 2171407101, computed crc = 1371274824)

[ https://issues.apache.org/jira/browse/KAFKA-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927500#comment-15927500 ] Jun Rao commented on KAFKA-4888: [~HanlinLiu], thanks for the info. Were there any issue with the network

Re: [DISCUSS] KIP-113: Support replicas movement between log directories

Hi, Dong, Thanks for the reply. 10. Could you comment on that? 11.2 "I am concerned that the ChangeReplicaDirRequest would be lost if broker restarts after it sends ChangeReplicaDirResponse but before it receives LeaderAndIsrRequest." In that case, the reassignment tool could detect that

[jira] [Commented] (KAFKA-4907) compacted topic shouldn't reject messages with old timestamp

[ https://issues.apache.org/jira/browse/KAFKA-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927460#comment-15927460 ] Jiangjie Qin commented on KAFKA-4907: - I see. Yeah, the default behavior probably should just be

[jira] [Assigned] (KAFKA-4907) compacted topic shouldn't reject messages with old timestamp

[ https://issues.apache.org/jira/browse/KAFKA-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiangjie Qin reassigned KAFKA-4907: --- Assignee: Jiangjie Qin > compacted topic shouldn't reject messages with old timestamp >

[jira] [Commented] (KAFKA-4906) Support 0.9 brokers with a newer Producer or Consumer version

[ https://issues.apache.org/jira/browse/KAFKA-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927449#comment-15927449 ] Grant Henke commented on KAFKA-4906: [~ijuma] Following up with a summary of some of our out of band

[jira] [Commented] (KAFKA-4907) compacted topic shouldn't reject messages with old timestamp

[ https://issues.apache.org/jira/browse/KAFKA-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927444#comment-15927444 ] Ismael Juma commented on KAFKA-4907: [~becket_qin], yes, so we should not reject messages based on

[jira] [Commented] (KAFKA-4907) compacted topic shouldn't reject messages with old timestamp

[ https://issues.apache.org/jira/browse/KAFKA-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927438#comment-15927438 ] Jiangjie Qin commented on KAFKA-4907: - [~ijuma] Hmm, if {{cleanup.policy}} is NOT set to {{delete}},

[jira] [Updated] (KAFKA-4906) Support 0.9 brokers with a newer Producer or Consumer version

[ https://issues.apache.org/jira/browse/KAFKA-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Henke updated KAFKA-4906: --- Fix Version/s: (was: 0.10.2.1) > Support 0.9 brokers with a newer Producer or Consumer version >

Re: [VOTE] KIP-111 Kafka should preserve the Principal generated by the PrincipalBuilder while processing the request received on socket channel, on the broker.

Hi Jun, Sorry for the delayed reply. I agree that the easiest thing will be to add an additional field in the Session class and we should be OK. But having a KafkaPrincipal and java Principal with in the same class looks little weird. So we can do this and slowly deprecate the usage of

[jira] [Updated] (KAFKA-4888) offset 449883 is invalid, cause: Record is corrupt (stored crc = 2171407101, computed crc = 1371274824)

[ https://issues.apache.org/jira/browse/KAFKA-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanlin Liu updated KAFKA-4888: -- Attachment: CRC_log.txt CRC_dump.cap CRC_log.txt is the log from our consumer and

[jira] [Commented] (KAFKA-4888) offset 449883 is invalid, cause: Record is corrupt (stored crc = 2171407101, computed crc = 1371274824)

[ https://issues.apache.org/jira/browse/KAFKA-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927415#comment-15927415 ] Hanlin Liu commented on KAFKA-4888: --- [~junrao][~ijuma] Hi, I am co-worker of [~chengc]. The kafka

[jira] [Comment Edited] (KAFKA-4907) compacted topic shouldn't reject messages with old timestamp

[ https://issues.apache.org/jira/browse/KAFKA-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927399#comment-15927399 ] Ismael Juma edited comment on KAFKA-4907 at 3/16/17 3:11 AM: - I think Jun is

[jira] [Commented] (KAFKA-4907) compacted topic shouldn't reject messages with old timestamp

[ https://issues.apache.org/jira/browse/KAFKA-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927399#comment-15927399 ] Ismael Juma commented on KAFKA-4907: I think Jun is suggesting that defaulting to `retention.ms` only

[jira] [Commented] (KAFKA-4907) compacted topic shouldn't reject messages with old timestamp

[ https://issues.apache.org/jira/browse/KAFKA-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927392#comment-15927392 ] Jiangjie Qin commented on KAFKA-4907: - [~junrao] Thanks for the explanation. Yes, that does sound an

[jira] [Commented] (KAFKA-4893) async topic deletion conflicts with max topic length

[ https://issues.apache.org/jira/browse/KAFKA-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927303#comment-15927303 ] Vahid Hashemian commented on KAFKA-4893: [~onurkaraman] Sure, I agree that your suggestion is the

[jira] [Commented] (KAFKA-4893) async topic deletion conflicts with max topic length

[ https://issues.apache.org/jira/browse/KAFKA-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927298#comment-15927298 ] Onur Karaman commented on KAFKA-4893: - Also [~vahid] while I agree reducing the limit is by far the

[jira] [Commented] (KAFKA-4844) kafka is holding open file descriptors

[ https://issues.apache.org/jira/browse/KAFKA-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927273#comment-15927273 ] chao commented on KAFKA-4844: - we want to delete index and log files under TOPIC_PARTITION_X/... and

[jira] [Commented] (KAFKA-4907) compacted topic shouldn't reject messages with old timestamp

[ https://issues.apache.org/jira/browse/KAFKA-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927265#comment-15927265 ] Jun Rao commented on KAFKA-4907: [~becket_qin], I was referring to the following code in KafkaConfig. If

Re: [VOTE] KIP-107: Add purgeDataBefore() API in AdminClient

When changing the code, I realized that it feels weird to have DeleteRequest and DeleteTopicsRequest. Thus I would follow the suggestion and change it to DeleteRecordsRequest in this KIP, unless we decide to use PurgeRequest. On Wed, Mar 15, 2017 at 12:04 PM, Dong Lin wrote:

Re: [DISCUSS] KIP-112: Handle disk failure for JBOD

Thanks for the updates Dong, they look good to me. Ismael On Wed, Mar 15, 2017 at 5:50 PM, Dong Lin wrote: > Hey Ismael, > > Sure, I have updated "Changes in Operational Procedures" section in KIP-113 > to specify the problem and solution with known disk failure. And I

[jira] [Commented] (KAFKA-4907) compacted topic shouldn't reject messages with old timestamp

[ https://issues.apache.org/jira/browse/KAFKA-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927231#comment-15927231 ] Jiangjie Qin commented on KAFKA-4907: - [~junrao] Are you referring to the log cleaner? The log cleaner

[jira] [Comment Edited] (KAFKA-4893) async topic deletion conflicts with max topic length

[ https://issues.apache.org/jira/browse/KAFKA-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927033#comment-15927033 ] Vahid Hashemian edited comment on KAFKA-4893 at 3/15/17 11:55 PM: --

[jira] [Commented] (KAFKA-4900) Brokers stuck in controller re-election loop after failing to register metrics

[ https://issues.apache.org/jira/browse/KAFKA-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927200#comment-15927200 ] Onur Karaman commented on KAFKA-4900: - I hadn't yet investigated why some of the fetchers hadn't

[jira] [Comment Edited] (KAFKA-4893) async topic deletion conflicts with max topic length

[ https://issues.apache.org/jira/browse/KAFKA-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927155#comment-15927155 ] Onur Karaman edited comment on KAFKA-4893 at 3/15/17 11:23 PM: --- [~ijuma] I

[jira] [Commented] (KAFKA-4893) async topic deletion conflicts with max topic length

[ https://issues.apache.org/jira/browse/KAFKA-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927155#comment-15927155 ] Onur Karaman commented on KAFKA-4893: - [~ijuma] I had thought about the additional fsync on the

[jira] [Commented] (KAFKA-4905) StreamPartitionAssignor doesn't respect subscriptions to assign partitions.

[ https://issues.apache.org/jira/browse/KAFKA-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927115#comment-15927115 ] Matthias J. Sax commented on KAFKA-4905: I see. If you use the same app-id, all instances must be

[jira] [Assigned] (KAFKA-4885) processstreamwithcachedstatestore and other streams benchmarks fail occasionally

[ https://issues.apache.org/jira/browse/KAFKA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang reassigned KAFKA-4885: Assignee: Guozhang Wang > processstreamwithcachedstatestore and other streams benchmarks

[jira] [Commented] (KAFKA-4905) StreamPartitionAssignor doesn't respect subscriptions to assign partitions.

[ https://issues.apache.org/jira/browse/KAFKA-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927100#comment-15927100 ] Florian Hussonnois commented on KAFKA-4905: --- Hi [~mjsax], I'm sorry if my explanation was not

[GitHub] kafka pull request #2565: MINOR: Use scale of 3 in streams benchmark by defa...

Github user guozhangwang closed the pull request at: https://github.com/apache/kafka/pull/2565 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature

Re: [DISCUSS] KIP 130: Expose states of active tasks to KafkaStreams public API

Thanks Guozhang for pointing me to the KIP-120. I've made some modifications to the KIP. I also proposed a new PR (there is still some tests to make). https://cwiki.apache.org/confluence/display/KAFKA/KIP+130%3A+Expose+states+of+active+tasks+to+KafkaStreams+public+API Exposing consumed offsets

[jira] [Commented] (KAFKA-4885) processstreamwithcachedstatestore and other streams benchmarks fail occasionally

[ https://issues.apache.org/jira/browse/KAFKA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927080#comment-15927080 ] ASF GitHub Bot commented on KAFKA-4885: --- GitHub user guozhangwang opened a pull request:

[GitHub] kafka pull request #2693: KAFKA-4885: Add client.close as exception handler ...

GitHub user guozhangwang opened a pull request: https://github.com/apache/kafka/pull/2693 KAFKA-4885: Add client.close as exception handler in streams system tests You can merge this pull request into a Git repository by running: $ git pull

Re: [DISCUSS] KIP-129: Kafka Streams Exactly-Once Semantics

Just a quick follow up: Our overall proposal is, to implement KIP-129 as is as a “Stream EoS 1.0” version. The raised concerns are all valid, but hard to quantify at the moment. Implementing KIP-129, that provides a clean design, allows us to gain more insight in the performance implications.

Re: [DISCUSS] KIP-126 - Allow KafkaProducer to batch based on uncompressed size

I see, then we are thinking about the same thing :) On Wed, Mar 15, 2017 at 2:26 PM, Ismael Juma wrote: > I meant finishing what's described in the following section and then > starting a discussion followed by a vote: > >

[jira] [Commented] (KAFKA-4907) compacted topic shouldn't reject messages with old timestamp

[ https://issues.apache.org/jira/browse/KAFKA-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927054#comment-15927054 ] Jun Rao commented on KAFKA-4907: [~becket_qin], could you confirm if this is a real issue? If so, would

[jira] [Created] (KAFKA-4907) compacted topic shouldn't reject messages with old timestamp

Jun Rao created KAFKA-4907: -- Summary: compacted topic shouldn't reject messages with old timestamp Key: KAFKA-4907 URL: https://issues.apache.org/jira/browse/KAFKA-4907 Project: Kafka Issue Type:

[jira] [Commented] (KAFKA-4893) async topic deletion conflicts with max topic length

[ https://issues.apache.org/jira/browse/KAFKA-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927038#comment-15927038 ] Ismael Juma commented on KAFKA-4893: Adding directories introduces more complexity due to fsync

[jira] [Commented] (KAFKA-4893) async topic deletion conflicts with max topic length

[ https://issues.apache.org/jira/browse/KAFKA-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927033#comment-15927033 ] Vahid Hashemian commented on KAFKA-4893: [~onurkaraman] What you suggested should work. Of course,

Re: [DISCUSS] KIP-129: Kafka Streams Exactly-Once Semantics

Hi, I want to pick up this thread again. As there are some concerns about the "producer per task" design, we did write up an alternative "producer per thread" design and discuss pros/cons of both approaches: https://docs.google.com/document/d/1CfOJaa6mdg5o7pLf_zXISV4oE0ZeMZwT_sG1QWgL4EE

[jira] [Commented] (KAFKA-4906) Support 0.9 brokers with a newer Producer or Consumer version

[ https://issues.apache.org/jira/browse/KAFKA-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927023#comment-15927023 ] Ismael Juma commented on KAFKA-4906: You also have to handle the fact that 0.9 brokers only support an

[jira] [Created] (KAFKA-4906) Support 0.9 brokers with a newer Producer or Consumer version

Grant Henke created KAFKA-4906: -- Summary: Support 0.9 brokers with a newer Producer or Consumer version Key: KAFKA-4906 URL: https://issues.apache.org/jira/browse/KAFKA-4906 Project: Kafka

Re: [DISCUSS] KIP-126 - Allow KafkaProducer to batch based on uncompressed size

I meant finishing what's described in the following section and then starting a discussion followed by a vote:

[jira] [Commented] (KAFKA-4905) StreamPartitionAssignor doesn't respect subscriptions to assign partitions.

[ https://issues.apache.org/jira/browse/KAFKA-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927000#comment-15927000 ] Matthias J. Sax commented on KAFKA-4905: I am not sure if I can follow: What I don't understand

[jira] [Updated] (KAFKA-4905) StreamPartitionAssignor doesn't respect subscriptions to assign partitions.

[ https://issues.apache.org/jira/browse/KAFKA-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Hussonnois updated KAFKA-4905: -- Summary: StreamPartitionAssignor doesn't respect subscriptions to assign partitions.

[jira] [Created] (KAFKA-4905) StreamPartitionAssignor doesn't respect subscriptions to asisgn partitions.

Florian Hussonnois created KAFKA-4905: - Summary: StreamPartitionAssignor doesn't respect subscriptions to asisgn partitions. Key: KAFKA-4905 URL: https://issues.apache.org/jira/browse/KAFKA-4905

Re: [DISCUSS] KIP-126 - Allow KafkaProducer to batch based on uncompressed size

Hi Ismael, KIP-4 is also the one that I was thinking about. We have introduced a DescribeConfigRequest there so the producer can easily get the configurations. By "another KIP" do you mean a new (or maybe extended) protocol or using that protocol in clients? Thanks, Jiangjie (Becket) Qin On

Re: [DISCUSS] KIP-126 - Allow KafkaProducer to batch based on uncompressed size

Hi Becket, How were you thinking of retrieving the configuration items you mentioned? I am asking because I was planning to post a KIP for Describe Configs (one of the protocols in KIP-4), which would expose such information. But maybe you are thinking of extending Metadata request? Ismael On

[jira] [Created] (KAFKA-4904) Performance of RocksDb with state record cache

Eno Thereska created KAFKA-4904: --- Summary: Performance of RocksDb with state record cache Key: KAFKA-4904 URL: https://issues.apache.org/jira/browse/KAFKA-4904 Project: Kafka Issue Type:

Re: [DISCUSS] KIP-132: Augment KStream.print to allow extra parameters in the printed string

Thanks for updating the KIP. It's in very good shape IMHO and I support this idea! -Matthias On 3/15/17 3:05 AM, Marc Juchli wrote: > Dear Matthias, > > The KIP is updated. I think it now contains all the information on that > page. > > Marc > > On Mon, Mar 13, 2017 at 9:37 PM Matthias J.

[jira] [Commented] (KAFKA-4770) KStreamAggregationDedupIntegrationTest fails occasionally

[ https://issues.apache.org/jira/browse/KAFKA-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926878#comment-15926878 ] Eno Thereska commented on KAFKA-4770: - Haven't seen this anymore. >

[jira] [Resolved] (KAFKA-4770) KStreamAggregationDedupIntegrationTest fails occasionally

[ https://issues.apache.org/jira/browse/KAFKA-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eno Thereska resolved KAFKA-4770. - Resolution: Cannot Reproduce > KStreamAggregationDedupIntegrationTest fails occasionally >

Build failed in Jenkins: kafka-trunk-jdk8 #1353

See Changes: [harsha] MINOR: Fix a documentation typo -- [...truncated 157.19 KB...] kafka.security.auth.SimpleAclAuthorizerTest > testLoadCache STARTED

[jira] [Commented] (KAFKA-3514) Stream timestamp computation needs some further thoughts

[ https://issues.apache.org/jira/browse/KAFKA-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926839#comment-15926839 ] Matthias J. Sax commented on KAFKA-3514: Thanks for you input. It's an interesting approach. We

Re: [DISCUSS] KIP-126 - Allow KafkaProducer to batch based on uncompressed size

Hi Jason, Good point. I was thinking about that, too. I was not sure if that is the right thing to do by default. If we assume people always set the batch size to max message size, splitting the oversized batch makes a lot of sense. But it seems possible that users want to control the memory

RE: documentation feedback

Hi Colin, Sorry, just reading this now. Looks like I don't have permissions to commit to a new branch to make pull request. I haven't made pull request before so may be doing it incorrectly ;) git push origin doc-security-console-example remote: Permission to apache/kafka.git denied to

Re: [VOTE] KIP-107: Add purgeDataBefore() API in AdminClient

Hey Jason, Ismael, Jeff, Regarding Purge vs PurgeRecords, would it be OK for me to make a followup patch to rename PurgeRequest to PurgeRecordsRequest (similarly for ProduceRequest and FetchRequest)? This is because I favor PurgeRequest over PurgeRecordsRequest before we rename ProduceRequest and

Build failed in Jenkins: kafka-trunk-jdk8 #1352

See Changes: [jason] MINOR: Improve log4j on stream thread and stream process -- [...truncated 157.19 KB...] kafka.security.auth.SimpleAclAuthorizerTest > testLoadCache

[GitHub] kafka pull request #2674: MINOR: Fix a documentation typo

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/2674 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

Jenkins build is back to normal : kafka-trunk-jdk8 #1351

See

Re: [DISCUSS] KIP-112: Handle disk failure for JBOD

Hey Ismael, Sure, I have updated "Changes in Operational Procedures" section in KIP-113 to specify the problem and solution with known disk failure. And I updated the "Test Plan" section to note that we have test in KIP-113 to verify that replicas already created on the good log directories will

[GitHub] kafka pull request #2685: MINOR: Improve log4j on stream thread and stream p...

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/2685 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

Jenkins build is back to normal : kafka-trunk-jdk7 #2015

See

[jira] [Commented] (KAFKA-4885) processstreamwithcachedstatestore and other streams benchmarks fail occasionally

[ https://issues.apache.org/jira/browse/KAFKA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926571#comment-15926571 ] Guozhang Wang commented on KAFKA-4885: -- [~damianguy] Well, as for the general solution in terms of

Re: [VOTE] KIP-107: Add purgeDataBefore() API in AdminClient

Hey Dong, Sorry for the late reply. Yes, I prefer PurgeRecordsRequest instead of PurgeRequest. DeleteRecords seems even better. As mentioned, I also think it would be a good idea to rename FetchRequest and ProduceRequest accordingly, but we need not consider that here. We could potentially rename

Re: [DISCUSS] KIP-126 - Allow KafkaProducer to batch based on uncompressed size

Hey Becket, Thanks for the KIP! The approach seems reasonable. One clarification: is the intent to do the splitting after the broker rejects the request with MESSAGE_TOO_LARGE, or prior to sending if the configured batch size is exceeded? -Jason On Mon, Mar 13, 2017 at 8:10 PM, Becket Qin

[jira] [Commented] (KAFKA-4903) Shell#runCommand does not clear the input buffer

[ https://issues.apache.org/jira/browse/KAFKA-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926406#comment-15926406 ] ASF GitHub Bot commented on KAFKA-4903: --- GitHub user cmccabe opened a pull request:

[GitHub] kafka pull request #2692: KAFKA-4903: Shell#runCommand does not clear the in...

GitHub user cmccabe opened a pull request: https://github.com/apache/kafka/pull/2692 KAFKA-4903: Shell#runCommand does not clear the input buffer You can merge this pull request into a Git repository by running: $ git pull https://github.com/cmccabe/kafka KAFKA-4903

Re: [VOTE] KIP-107: Add purgeDataBefore() API in AdminClient

Hi Dong, I think your suggestion of including `Records` in the name of the new request and renaming `Fetch` and `Produce` to be `FetchRecords` and `ProduceRecords` is a good one. We can do the the renames separately. It's a compatible change since the name of the API is never exchanged with

[jira] [Created] (KAFKA-4903) Shell#runCommand does not clear the input buffer

Colin P. McCabe created KAFKA-4903: -- Summary: Shell#runCommand does not clear the input buffer Key: KAFKA-4903 URL: https://issues.apache.org/jira/browse/KAFKA-4903 Project: Kafka Issue

[jira] [Commented] (KAFKA-4902) Utils#delete should correctly handle I/O errors and symlinks

[ https://issues.apache.org/jira/browse/KAFKA-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926382#comment-15926382 ] ASF GitHub Bot commented on KAFKA-4902: --- GitHub user cmccabe opened a pull request:

[GitHub] kafka pull request #2691: KAFKA-4902: Utils#delete should correctly handle I...

GitHub user cmccabe opened a pull request: https://github.com/apache/kafka/pull/2691 KAFKA-4902: Utils#delete should correctly handle I/O errors and symlinks You can merge this pull request into a Git repository by running: $ git pull https://github.com/cmccabe/kafka

[jira] [Created] (KAFKA-4902) Utils#delete should correctly handle I/O errors and symlinks

Colin P. McCabe created KAFKA-4902: -- Summary: Utils#delete should correctly handle I/O errors and symlinks Key: KAFKA-4902 URL: https://issues.apache.org/jira/browse/KAFKA-4902 Project: Kafka

[jira] [Commented] (KAFKA-4888) offset 449883 is invalid, cause: Record is corrupt (stored crc = 2171407101, computed crc = 1371274824)

[ https://issues.apache.org/jira/browse/KAFKA-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926322#comment-15926322 ] Jun Rao commented on KAFKA-4888: [~eduardo.s.neto] and [~chengc], is the issue persistent, i.e., if you

[GitHub] kafka pull request #2690: HOTFIX: Fix header in ByteArrayConverter

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/2690 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[jira] [Commented] (KAFKA-4643) Improve test coverage of StreamsKafkaClient

[ https://issues.apache.org/jira/browse/KAFKA-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926216#comment-15926216 ] Damian Guy commented on KAFKA-4643: --- [~adyachkov] true. I missed that! Though the unit tests for this

[jira] [Reopened] (KAFKA-4643) Improve test coverage of StreamsKafkaClient

[ https://issues.apache.org/jira/browse/KAFKA-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damian Guy reopened KAFKA-4643: --- > Improve test coverage of StreamsKafkaClient > --- > >

[jira] [Updated] (KAFKA-4901) Make ProduceRequest thread-safe

[ https://issues.apache.org/jira/browse/KAFKA-4901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4901: --- Assignee: Ismael Juma Status: Patch Available (was: Open) > Make ProduceRequest thread-safe >

[jira] [Created] (KAFKA-4901) Make ProduceRequest thread-safe

Ismael Juma created KAFKA-4901: -- Summary: Make ProduceRequest thread-safe Key: KAFKA-4901 URL: https://issues.apache.org/jira/browse/KAFKA-4901 Project: Kafka Issue Type: Bug

[GitHub] kafka pull request #2690: HOTFIX: Fix header in ByteArrayConverter

GitHub user ijuma opened a pull request: https://github.com/apache/kafka/pull/2690 HOTFIX: Fix header in ByteArrayConverter You can merge this pull request into a Git repository by running: $ git pull https://github.com/ijuma/kafka fix-header-in-byte-array-converter

[jira] [Commented] (KAFKA-4643) Improve test coverage of StreamsKafkaClient

[ https://issues.apache.org/jira/browse/KAFKA-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926189#comment-15926189 ] Andrey Dyachkov commented on KAFKA-4643: [~damianguy] exceptions paths are not tested anyway. >

[GitHub] kafka pull request #2689: MINOR: Make ProduceRequest thread-safe

GitHub user ijuma opened a pull request: https://github.com/apache/kafka/pull/2689 MINOR: Make ProduceRequest thread-safe You can merge this pull request into a Git repository by running: $ git pull https://github.com/ijuma/kafka produce-request-thread-safety Alternatively

[jira] [Commented] (KAFKA-4863) Querying window store may return unwanted keys

[ https://issues.apache.org/jira/browse/KAFKA-4863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926122#comment-15926122 ] ASF GitHub Bot commented on KAFKA-4863: --- GitHub user dguy opened a pull request:

[GitHub] kafka pull request #2688: KAFKA-4863: Querying window store may return unwan...

GitHub user dguy opened a pull request: https://github.com/apache/kafka/pull/2688 KAFKA-4863: Querying window store may return unwanted keys. Backport to 0.10.2 You can merge this pull request into a Git repository by running: $ git pull https://github.com/dguy/kafka

[jira] [Comment Edited] (KAFKA-3514) Stream timestamp computation needs some further thoughts

[ https://issues.apache.org/jira/browse/KAFKA-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926036#comment-15926036 ] Arun Mathew edited comment on KAFKA-3514 at 3/15/17 12:15 PM: -- Hi [~mjsax],

[jira] [Commented] (KAFKA-3514) Stream timestamp computation needs some further thoughts

[ https://issues.apache.org/jira/browse/KAFKA-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926036#comment-15926036 ] Arun Mathew commented on KAFKA-3514: Hi [~mjsax] [~mihbor] . We were building an audit trail for kafka

Re: [DISCUSS] KIP-132: Augment KStream.print to allow extra parameters in the printed string

Dear Matthias, The KIP is updated. I think it now contains all the information on that page. Marc On Mon, Mar 13, 2017 at 9:37 PM Matthias J. Sax wrote: > Marc, > > Thanks for the KIP. > > Can you please update the KIP in a way such that it is self contained. > Right

Re: [DISCUSS] KIP-112: Handle disk failure for JBOD

Hi Dong, Yes, that sounds good to me. I'd list option 2 first since that is safe and, as you said, no worse than what happens today. The file approach is a bit hacky as you said, so it may be a bit fragile. Not sure if we really want to mention that. :) About the note in KIP-112 versus adding

[jira] [Commented] (KAFKA-4888) offset 449883 is invalid, cause: Record is corrupt (stored crc = 2171407101, computed crc = 1371274824)

[ https://issues.apache.org/jira/browse/KAFKA-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925851#comment-15925851 ] Ismael Juma commented on KAFKA-4888: [~chengc], is the Kafka version and other details the same as the

[jira] [Updated] (KAFKA-4888) offset 449883 is invalid, cause: Record is corrupt (stored crc = 2171407101, computed crc = 1371274824)

[ https://issues.apache.org/jira/browse/KAFKA-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4888: --- Fix Version/s: (was: 0.10.1.1) > offset 449883 is invalid, cause: Record is corrupt (stored crc =

[jira] [Commented] (KAFKA-4487) Tests should be run in Jenkins with INFO or DEBUG level

[ https://issues.apache.org/jira/browse/KAFKA-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925832#comment-15925832 ] Ismael Juma commented on KAFKA-4487: [~enothereska], yeah, we'd have to check how much additional

[jira] [Commented] (KAFKA-4643) Improve test coverage of StreamsKafkaClient

[ https://issues.apache.org/jira/browse/KAFKA-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925830#comment-15925830 ] Damian Guy commented on KAFKA-4643: --- [~adyachkov] it looks like the method has been removed since this

[jira] [Resolved] (KAFKA-4643) Improve test coverage of StreamsKafkaClient

[ https://issues.apache.org/jira/browse/KAFKA-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damian Guy resolved KAFKA-4643. --- Resolution: Won't Fix Method that wasn't covered has subsequently been removed > Improve test

[jira] [Commented] (KAFKA-4885) processstreamwithcachedstatestore and other streams benchmarks fail occasionally

[ https://issues.apache.org/jira/browse/KAFKA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925825#comment-15925825 ] Damian Guy commented on KAFKA-4885: --- [~guozhang] 1. We give users a chance to shutdown the whole

[jira] [Commented] (KAFKA-4487) Tests should be run in Jenkins with INFO or DEBUG level

[ https://issues.apache.org/jira/browse/KAFKA-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925757#comment-15925757 ] Eno Thereska commented on KAFKA-4487: - There are cases when the disk gets full when running with DEBUG

[jira] [Commented] (KAFKA-4888) offset 449883 is invalid, cause: Record is corrupt (stored crc = 2171407101, computed crc = 1371274824)

[ https://issues.apache.org/jira/browse/KAFKA-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925720#comment-15925720 ] Cheng Chen commented on KAFKA-4888: --- [~eduardo.s.neto] We saw the same problem, did you deploy our

[jira] [Comment Edited] (KAFKA-4900) Brokers stuck in controller re-election loop after failing to register metrics

[ https://issues.apache.org/jira/browse/KAFKA-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925611#comment-15925611 ] Onur Karaman edited comment on KAFKA-4900 at 3/15/17 6:44 AM: -- For reference,

[jira] [Commented] (KAFKA-4900) Brokers stuck in controller re-election loop after failing to register metrics

[ https://issues.apache.org/jira/browse/KAFKA-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925611#comment-15925611 ] Onur Karaman commented on KAFKA-4900: - For reference, I think the controller was changing every 3