[jira] [Commented] (KAFKA-5344) Change message.timestamp.difference.max.ms back to Long.MaxValue

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

[GitHub] kafka pull request #3163: KAFKA-5344: set message.timestamp.difference.max.m...

GitHub user becketqin opened a pull request: https://github.com/apache/kafka/pull/3163 KAFKA-5344: set message.timestamp.difference.max.ms back to Long.MaxValue You can merge this pull request into a Git repository by running: $ git pull https://github.com/becketqin/kafka

[jira] [Created] (KAFKA-5344) Change message.timestamp.difference.max.ms back to Long.MaxValue

Jiangjie Qin created KAFKA-5344: --- Summary: Change message.timestamp.difference.max.ms back to Long.MaxValue Key: KAFKA-5344 URL: https://issues.apache.org/jira/browse/KAFKA-5344 Project: Kafka

RE?? [DISCUSS] KIP-148: Add a connect timeout for client

Hi Guozhang I do agree for adding a universal `connect.timeout.ms`, and in another KIP consider adding per-request-type timeout overrides And is there any other comments about this KIP? Looking forward to the comments. Thanks David -- --

[jira] [Updated] (KAFKA-5340) Add additional test cases for batch splitting to ensure idempotent/transactional metadata is preserved

[ https://issues.apache.org/jira/browse/KAFKA-5340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gustafson updated KAFKA-5340: --- Status: Patch Available (was: Open) > Add additional test cases for batch splitting to

[jira] [Commented] (KAFKA-5340) Add additional test cases for batch splitting to ensure idempotent/transactional metadata is preserved

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

[GitHub] kafka pull request #3162: KAFKA-5340: Batch splitting should preserve magic ...

GitHub user hachikuji opened a pull request: https://github.com/apache/kafka/pull/3162 KAFKA-5340: Batch splitting should preserve magic and transactional flag You can merge this pull request into a Git repository by running: $ git pull https://github.com/hachikuji/kafka

[jira] [Commented] (KAFKA-5337) Partition assignment strategy that distributes lag evenly across consumers in each group

[ https://issues.apache.org/jira/browse/KAFKA-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027969#comment-16027969 ] ASF GitHub Bot commented on KAFKA-5337: --- Github user grantneale closed the pull request at:

[GitHub] kafka pull request #3158: KAFKA-5337: LagBasedAssignor partition assignment ...

Github user grantneale closed the pull request at: https://github.com/apache/kafka/pull/3158 --- 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] [Comment Edited] (KAFKA-4304) Extend Interactive Queries for return latest update timestamp per key

[ https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027964#comment-16027964 ] Jeyhun Karimov edited comment on KAFKA-4304 at 5/28/17 10:34 PM: - >From

[jira] [Assigned] (KAFKA-4304) Extend Interactive Queries for return latest update timestamp per key

[ https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeyhun Karimov reassigned KAFKA-4304: - Assignee: Jeyhun Karimov > Extend Interactive Queries for return latest update timestamp

[jira] [Comment Edited] (KAFKA-4304) Extend Interactive Queries for return latest update timestamp per key

[ https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027964#comment-16027964 ] Jeyhun Karimov edited comment on KAFKA-4304 at 5/28/17 10:25 PM: - >From

[jira] [Commented] (KAFKA-4304) Extend Interactive Queries for return latest update timestamp per key

[ https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027964#comment-16027964 ] Jeyhun Karimov commented on KAFKA-4304: --- >From the user perspective, one would query

[jira] [Updated] (KAFKA-4304) Extend Interactive Queries for return latest update timestamp per key

[ https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax updated KAFKA-4304: --- Labels: needs-kip (was: ) > Extend Interactive Queries for return latest update timestamp

[jira] [Commented] (KAFKA-4304) Extend Interactive Queries for return latest update timestamp per key

[ https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027963#comment-16027963 ] Matthias J. Sax commented on KAFKA-4304: Not sure how to implement it... :) Why do you think a new

[jira] [Updated] (KAFKA-4304) Extend Interactive Queries for return latest update timestamp per key

[ https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax updated KAFKA-4304: --- Labels: (was: newbie++) > Extend Interactive Queries for return latest update timestamp per

[jira] [Updated] (KAFKA-5251) Producer should drop queued sends when transaction is aborted

[ https://issues.apache.org/jira/browse/KAFKA-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gustafson updated KAFKA-5251: --- Status: Patch Available (was: Open) > Producer should drop queued sends when transaction is

[jira] [Commented] (KAFKA-5251) Producer should drop queued sends when transaction is aborted

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

[GitHub] kafka pull request #3161: KAFKA-5251: Producer should cancel unsent AddParti...

GitHub user hachikuji opened a pull request: https://github.com/apache/kafka/pull/3161 KAFKA-5251: Producer should cancel unsent AddPartitions and Produce requests on abort You can merge this pull request into a Git repository by running: $ git pull

[jira] [Commented] (KAFKA-4304) Extend Interactive Queries for return latest update timestamp per key

[ https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027958#comment-16027958 ] Jeyhun Karimov commented on KAFKA-4304: --- [~mjsax] I completely forgot this issue. Sorry for super

[jira] [Updated] (KAFKA-5343) MockProducer should not handle send/ProducerRecord after close

[ https://issues.apache.org/jira/browse/KAFKA-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Grotzke updated KAFKA-5343: -- Description: Currently {{MockProducer}} implements {{close}} with void, i.e. it just does

[jira] [Updated] (KAFKA-5343) MockProducer should not handle send/ProducerRecord after close

[ https://issues.apache.org/jira/browse/KAFKA-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Grotzke updated KAFKA-5343: -- Description: Currently {{MockProducer}} implements {{close}} with void, i.e. it just does

[jira] [Created] (KAFKA-5343) MockProducer should not handle send/ProducerRecord after close

Martin Grotzke created KAFKA-5343: - Summary: MockProducer should not handle send/ProducerRecord after close Key: KAFKA-5343 URL: https://issues.apache.org/jira/browse/KAFKA-5343 Project: Kafka

[jira] [Updated] (KAFKA-5343) MockProducer should not handle send/ProducerRecord after close

[ https://issues.apache.org/jira/browse/KAFKA-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Grotzke updated KAFKA-5343: -- Description: Currently {{MockProducer}} implements {{close}} with void, i.e. it just does

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

See

[jira] [Created] (KAFKA-5342) Distinguish abortable failures in transactional producer

Jason Gustafson created KAFKA-5342: -- Summary: Distinguish abortable failures in transactional producer Key: KAFKA-5342 URL: https://issues.apache.org/jira/browse/KAFKA-5342 Project: Kafka

Jenkins build is back to normal : kafka-0.11.0-jdk7 #42

See

Re: [DISCUSS]: KIP-159: Introducing Rich functions to Streams

After your response on KIP-149 related with ValueTransformerSupplier, everything you mentioned now makes complete sense. Thanks for clarification. Just a note: We will have additional (to KIP-149) overloaded methods: for each withKey and withoutKey methods (ValueMapper and ValueMapperWithKey) we

Re: [DISCUSS]: KIP-149: Enabling key access in ValueTransformer, ValueMapper, and ValueJoiner

Thanks for clarification Matthias, now everything is clear. On Sun, May 28, 2017 at 6:21 PM Matthias J. Sax wrote: > I don't think we can drop ValueTransformerSupplier. If you don't have an > supplier, you only get a single instance of your function. But for a > stateful

[jira] [Resolved] (KAFKA-5316) Log cleaning can increase message size and cause cleaner to crash with buffer overflow

[ https://issues.apache.org/jira/browse/KAFKA-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gustafson resolved KAFKA-5316. Resolution: Fixed Fix Version/s: 0.11.0.0 Issue resolved by pull request 3142

[GitHub] kafka pull request #3142: KAFKA-5316: LogCleaner should account for larger r...

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/3142 --- 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-5316) Log cleaning can increase message size and cause cleaner to crash with buffer overflow

[ https://issues.apache.org/jira/browse/KAFKA-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027865#comment-16027865 ] ASF GitHub Bot commented on KAFKA-5316: --- Github user asfgit closed the pull request at:

Re: [DISCUSS]: KIP-159: Introducing Rich functions to Streams

Thanks for you comments Jeyhun, I agree about the disadvantages. Only the punctuation part is something I don't buy. IMHO, RichFunctions should not allow to register and use punctuation. If you need punctuation, you should use #transform() or similar. Note, that we plan to provide `RecordContext`

Re: Efficient way of Searching Messages By Timestamp - Kafka

Hi Dev, It would be great if anybody share your experience on Search Message by Timestamp .. Cheer's, Senthil On May 28, 2017 2:08 AM, "SenthilKumar K" wrote: > Hi Team , Any help here Pls ? > > Cheers, > Senthil > > On Sat, May 27, 2017 at 8:25 PM, SenthilKumar K

Re: [DISCUSS]: KIP-149: Enabling key access in ValueTransformer, ValueMapper, and ValueJoiner

I don't think we can drop ValueTransformerSupplier. If you don't have an supplier, you only get a single instance of your function. But for a stateful transformation, we need multiple instances (one for each task) of ValueTransformer. We don't need suppliers for functions like "ValueMapper" etc

[jira] [Comment Edited] (KAFKA-4273) Streams DSL - Add TTL / retention period support for intermediate topics and state stores

[ https://issues.apache.org/jira/browse/KAFKA-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027841#comment-16027841 ] Ayush Verma edited comment on KAFKA-4273 at 5/28/17 3:30 PM: - I have a use

[jira] [Commented] (KAFKA-4273) Streams DSL - Add TTL / retention period support for intermediate topics and state stores

[ https://issues.apache.org/jira/browse/KAFKA-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027841#comment-16027841 ] Ayush Verma commented on KAFKA-4273: I have a use case where I am storing some aggregates for flights

Re: KIP-162: Enable topic deletion by default

+1 On Sun, May 28, 2017 at 6:57 AM, Vahid S Hashemian < vahidhashem...@us.ibm.com> wrote: > Sure, that sounds good. > > I suggested that to keep command line behavior consistent. > Plus, removal of ACL access is something that can be easily undone, but > topic deletion is not reversible. > So,

Re: [DISCUSS]: KIP-149: Enabling key access in ValueTransformer, ValueMapper, and ValueJoiner

Hi, I updated KIP. Just to avoid misunderstanding, I meant deprecating ValueTransformerSupplier and I am ok with ValueTransformer. So instead of using ValueTransformerSupplier can't we directly use ValueTransformer or ValueTransformerWithKey? Btw, in current design all features of

[jira] [Created] (KAFKA-5341) Add unavailablePartitionCount and per-partition Unavailable metrics (KIP-164)

Dong Lin created KAFKA-5341: --- Summary: Add unavailablePartitionCount and per-partition Unavailable metrics (KIP-164) Key: KAFKA-5341 URL: https://issues.apache.org/jira/browse/KAFKA-5341 Project: Kafka

[DISCUSS] KIP-164 Add unavailablePartitionCount and per-partition Unavailable metrics

Hi, We created KIP-164 to propose adding per-partition metric *Unavailable* and per-broker metric *UnavailablePartitionCount* The KIP wik can be found at https://cwiki.apache.org/confluence/display/KAFKA/KIP-164-+Add+unavailablePartitionCount+and+per-partition+Unavailable+metrics . Comments are