[jira] [Created] (KAFKA-7068) ConfigTransformer doesn't handle null values

Magesh kumar Nandakumar created KAFKA-7068: -- Summary: ConfigTransformer doesn't handle null values Key: KAFKA-7068 URL: https://issues.apache.org/jira/browse/KAFKA-7068 Project: Kafka

Build failed in Jenkins: kafka-0.10.2-jdk7 #216

See Changes: [me] KAFKA-7058: Comparing schema default values using Objects#deepEquals() -- [...truncated 1.31 MB...] org.apache.kafka.streams.processor.internals.StreamTh

Jenkins build is back to normal : kafka-0.10.0-jdk7 #221

See

Build failed in Jenkins: kafka-0.11.0-jdk7 #382

See Changes: [me] KAFKA-7058: Comparing schema default values using Objects#deepEquals() -- [...truncated 903.89 KB...] kafka.producer.ProducerTest > testSendToNewTopic S

[jira] [Resolved] (KAFKA-7068) ConfigTransformer doesn't handle null values

[ https://issues.apache.org/jira/browse/KAFKA-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ewen Cheslack-Postava resolved KAFKA-7068. -- Resolution: Fixed Fix Version/s: 2.1.0 Issue resolved by pull request 52

Build failed in Jenkins: kafka-trunk-jdk10 #227

See Changes: [me] KAFKA-7068: Handle null config values during transform (KIP-297) -- [...truncated 1.57 MB...] kafka.coordinator.transaction.TransactionCoordinatorTest >

Re: [VOTE] KIP-280: Enhanced log compaction

Let me rephrase your answer to make sure I understand what you suggest: If compaction strategy is configured to use "offset", and if there is a header in the record with `key == offset`, than we should use the value of the record header instead of the actual record offset? Do I understand this co

Re: [VOTE] KIP-280: Enhanced log compaction

My previous reply was just an alternative for consideration. bq. than a second user B can add a header with key "offset" and thus break the intention of user A I didn't see such scenario after reading the KIP. Maybe add this as reasoning for the current approach ? I wonder how user B gets to kn

Re: [VOTE] KIP-280: Enhanced log compaction

I think refactoring the value `header-key` to `header=` is a better idea, to allow users to specify using the header key which happen to be the same name to either `offset` or `timestamp`. Guozhang On Sun, Jun 17, 2018 at 5:36 PM, Ted Yu wrote: > My previous reply was just an alternative for c

Re: [VOTE] KIP-280: Enhanced log compaction

Well, for "offset" and "timestamp" policy, not communication between both is required. Only if headers are used, user A should communicate the corresponding header key to user B. @Luis: can you update the KIP accordingly? -Matthias On 6/17/18 5:36 PM, Ted Yu wrote: > My previous reply was ju

Re: Error in Kafka Stream

Hello Amandeep, What file system are you using? Also is `/opt/info` a temp folder that can be auto-cleared from time to time? Guozhang On Fri, Jun 15, 2018 at 6:39 AM, Amandeep Singh wrote: > Hi, > > > > I am getting the below error while processign data with kafka stream. The > application

Jenkins build is back to normal : kafka-trunk-jdk10 #228

See

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

See Changes: [wangguoz] KAFKA-7048 NPE when creating connector (#5202) -- [...truncated 944.62 KB...] kafka.zookeeper.ZooKeeperClientTest > testBlockOnRequestCompletionFr

Re: [DISCUSSION] KIP-300: Add Windowed KTable API in StreamsBuilder

Thanks for the KIP Boyang, I made a pass over the KIP and the PR and have some comments: 1. About the public API, I agree with Matthias that we can consider exposing the `innerDeserializer` and `innerSerializer` in the Time/SessionWindowSerializer/Deserializer, and the `innerSerde` in ` WrapperSer