KIP-669: Preserve Source Partition in Kafka Streams from context
Hi, I have submitted a new KIP for preserving processor record context partition from source. I am looking for suggestions/comments. In most use cases where source message is getting transformed and sent to a target topic, where 1. number of partitions on source and sink topic are same 2. there is no change to the key 3. more importantly if we would like to preserve the partition as is without re-deriving using partition from context would help. I am aware of one caveat where record processor context partition is not known in stream punctuation. Please look over the KIP and chime in more ideas Thanks Balan
Request for KIP creation access
Hi, I would like to have the access for creating KIP for Kafka. My wiki id is ksbalan2016. I have opened a Jira ticket and had brief interaction with Mathias on stack overflow about this ticket. He would like me to open a KIp in this regards. Thanks for your help Please let me know if you have additional questions Thanks again Balan
[jira] [Resolved] (KAFKA-7387) Kafka distributed worker reads config from backup while launching connector
[ https://issues.apache.org/jira/browse/KAFKA-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] satyanarayan komandur resolved KAFKA-7387. -- Resolution: Not A Bug Issue is with the JDBC connector and not with the kafka connect framework > Kafka distributed worker reads config from backup while launching connector > --- > > Key: KAFKA-7387 > URL: https://issues.apache.org/jira/browse/KAFKA-7387 > Project: Kafka > Issue Type: Bug > Reporter: satyanarayan komandur >Priority: Minor > > While launching kafka connector using REST API in the distributed mode, the > kafka worker uses the old configuration. Normally this is fine when we > relaunch the connector without changing configuration. > If the prior failure is related to a connector configuration issue and we are > relaunching, worker is still using old configuration for the first time > though subsequently it is updating the new configuration supplied. So > essentially we have to launch it twice in such cases. This behavior is not > changing even if we call the update config first and then launching the > connector > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-7387) Kafka distributed worker reads config from backup while launching connector
satyanarayan komandur created KAFKA-7387: Summary: Kafka distributed worker reads config from backup while launching connector Key: KAFKA-7387 URL: https://issues.apache.org/jira/browse/KAFKA-7387 Project: Kafka Issue Type: Bug Reporter: satyanarayan komandur While launching kafka connector using REST API in the distributed mode, the kafka worker uses the old configuration. Normally this is fine when we relaunch the connector without changing configuration. If the prior failure is related to a connector configuration issue and we are relaunching, worker is still using old configuration for the first time though subsequently it is updating the new configuration supplied. So essentially we have to launch it twice in such cases. This behavior is not changing even if we call the update config first and then launching the connector -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-7239) Kafka Connect secret externalization not working
satyanarayan komandur created KAFKA-7239: Summary: Kafka Connect secret externalization not working Key: KAFKA-7239 URL: https://issues.apache.org/jira/browse/KAFKA-7239 Project: Kafka Issue Type: Bug Reporter: satyanarayan komandur I used the Kafka FileConfigProvider to externalize the properties like connection.user and connection.password for JDBC source connector. I noticed that the values in the connection properties are being replaced after the connector has attempted to establish a connection with original key/value pairs (untransformed). This is resulting a failure in connection. I am not sure if this issue belong to Kafka Connector framework or its an issue with JDBC Source Connector -- This message was sent by Atlassian JIRA (v7.6.3#76005)
