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

[Guozhang Wang]

+1. Thanks!

On Sat, Jul 8, 2017 at 1:35 AM, Damian Guy  wrote:

> +1
> On Fri, 7 Jul 2017 at 16:08, Eno Thereska  wrote:
>
> > +1 (non-binding) Thanks.
> >
> > Eno
> > > On 6 Jul 2017, at 21:49, Gwen Shapira  wrote:
> > >
> > > +1
> > >
> > > On Wed, Jul 5, 2017 at 9:25 AM Matthias J. Sax 
> > > wrote:
> > >
> > >> +1
> > >>
> > >> On 6/27/17 1:41 PM, Jeyhun Karimov wrote:
> > >>> Dear all,
> > >>>
> > >>> I would like to start the vote on KIP-149 [1].
> > >>>
> > >>>
> > >>> Cheers,
> > >>> Jeyhun
> > >>>
> > >>>
> > >>> [1]
> > >>>
> > >>
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 149%3A+Enabling+key+access+in+ValueTransformer%2C+
> ValueMapper%2C+and+ValueJoiner
> > >>>
> > >>
> > >>
> >
> >
>



-- 
-- Guozhang

[jira] [Resolved] (KAFKA-5598) Make OffsetReader accessible in ConnectorContext

[Oleg Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kuznetsov resolved KAFKA-5598.
---
Resolution: Duplicate

> Make OffsetReader accessible in ConnectorContext
> 
>
> Key: KAFKA-5598
> URL: https://issues.apache.org/jira/browse/KAFKA-5598
> Project: Kafka
>  Issue Type: Improvement
>  Components: KafkaConnect
>Affects Versions: 0.11.0.0
>Reporter: Oleg Kuznetsov
>
> It is useful to read offset in SourceConnector, but now OffsetReader is 
> accessible only in SourceTaskContext.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (KAFKA-5598) Make OffsetReader accessible in ConnectorContext

[Oleg Kuznetsov (JIRA)]

Oleg Kuznetsov created KAFKA-5598:
-

 Summary: Make OffsetReader accessible in ConnectorContext
 Key: KAFKA-5598
 URL: https://issues.apache.org/jira/browse/KAFKA-5598
 Project: Kafka
  Issue Type: Improvement
  Components: KafkaConnect
Affects Versions: 0.11.0.0
Reporter: Oleg Kuznetsov


It is useful to read offset in SourceConnector, but now OffsetReader is 
accessible only in SourceTask.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] kafka pull request #3530: KAFKA-5595: Ensure client connection ids are not r...

[rajinisivaram]

GitHub user rajinisivaram reopened a pull request:

https://github.com/apache/kafka/pull/3530

KAFKA-5595: Ensure client connection ids are not reused too quickly

When there are broker delays that cause a response to take longer than 
`connections.max.idle.ms`, connections may be closed by the broker (as well as 
by the client) before the response is processed.
If the port is reused, broker may send the outstanding response to a new 
connection with the reused port. The new connection will end up with 
correlation id mismatch, requiring process restart. This is also a security 
exposure since clients receive response intended for the wrong connection.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rajinisivaram/kafka KAFKA-5595

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/kafka/pull/3530.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3530


commit 99f3374b5c3b0cb5efcdfe4c553aac943297b016
Author: Rajini Sivaram 
Date:   2017-07-15T13:01:47Z

KAFKA-5595: Ensure client connection ids are not reused too quickly




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] kafka pull request #3530: KAFKA-5595: Ensure client connection ids are not r...

[rajinisivaram]

Github user rajinisivaram closed the pull request at:

https://github.com/apache/kafka/pull/3530


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Behavior when kafka producer is network partitioned

[Abhishek Agarwal]

What is the behaviour in 0.10.x if kafka producer is not able to reach any
of the broker for a brief duration?

>From what I understand from the code, all the nodes will be in disconnected
state. Since there is no node to query to, client will never query any node
and update the cluster. Even if kafka brokers come up or the network comes
back up, connection state will remain the same. Producing messages will
continue to fail till the kafka client is restarted. Is this understanding
correct?

-- 
Regards,
Abhishek Agarwal

Re: kafka connect

[mayank rathi]

In case you do not find Kafka Connector for listening to TCP sockets, you
can use NiFi for this task. NiFi has a processor to listen to TCP messages.

On Tue, Jul 4, 2017 at 1:26 PM, Clay Teahouse 
wrote:

> Hello All,
>
> I have a few questions regarding kafka connect. I'd appreciate your
> replies.
>
> 1) Is there a kafka connector for listening to tcp sockets?
>
> 2) If there a protobuf converter that can deal with variable length
> messages? Meaning read the prefix that specifies the length and use the
> specified length to read the actual message?
>
> thanks
> Clay
>



-- 
NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy
all copies of the original message.

[GitHub] kafka pull request #3535: KAFKA-5597: Autogenerate producer sender metrics.

[wushujames]

GitHub user wushujames opened a pull request:

https://github.com/apache/kafka/pull/3535

KAFKA-5597: Autogenerate producer sender metrics.

Subtask of https://issues.apache.org/jira/browse/KAFKA-3480

The changes are very similar to what was done for the consumer in 
https://issues.apache.org/jira/browse/KAFKA-5191 (pull request 
https://github.com/apache/kafka/pull/2993)

A screenshot of the docs are here:
![producer metrics 
docs](https://user-images.githubusercontent.com/677529/28245950-96b0c20a-69c6-11e7-8631-11fd55a0ad92.png)


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/wushujames/kafka producer_sender_metrics_docs

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/kafka/pull/3535.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3535


commit 33f876fa471048ec6ddd7c05dbd5935d0157eca3
Author: James Cheng 
Date:   2017-07-16T08:29:30Z

Autogenerate producer sender metrics.




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (KAFKA-5597) Autogenerate Producer sender metrics

[James Cheng (JIRA)]

James Cheng created KAFKA-5597:
--

 Summary: Autogenerate Producer sender metrics
 Key: KAFKA-5597
 URL: https://issues.apache.org/jira/browse/KAFKA-5597
 Project: Kafka
  Issue Type: Sub-task
Reporter: James Cheng






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] kafka pull request #3478: KAFKA-3539: KafkaProducer.send() should not block

[evis]

Github user evis closed the pull request at:

https://github.com/apache/kafka/pull/3478


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---