Thanks for the reminder.
+1 (non-binding)
Ryanne
On Fri, Apr 12, 2019, 11:13 AM Paul Davidson
wrote:
> Hi everyone. Just a reminder that KIP-411 is now open for voting. No votes
> received yet!
>
> Thanks,
>
> Paul
>
> On Thu, Apr 4, 2019 at 9:09 AM pdavidson wrote:
>
> > Thanks Randall.
Hi everyone. Just a reminder that KIP-411 is now open for voting. No votes
received yet!
Thanks,
Paul
On Thu, Apr 4, 2019 at 9:09 AM pdavidson wrote:
> Thanks Randall. You're absolutely right that Worker creates the clients
> before passing them to the tasks, so I'm very happy with your
Thanks Randall. You're absolutely right that Worker creates the clients
before passing them to the tasks, so I'm very happy with your changes.
Paul
On Thu, Apr 4, 2019 at 8:02 AM Randall Hauch wrote:
> Sounds great.
>
> I did make a few minor grammatical edits to the "Proposed Changes"
Sounds great.
I did make a few minor grammatical edits to the "Proposed Changes" section
to avoid the notion that the sink and source tasks create the consumers and
producers, respectively. I think it's important to accurately denote that
the framework creates the producers and consumers for the
Thanks Randall, I updated the proposal as suggested. Let me know if any
other changes need to be made, otherwise I think the KIP-411 proposal is
ready to finalize. I will aim to call a vote on Friday.
On Mon, Mar 25, 2019 at 7:12 AM Ryanne Dolan wrote:
> Randall, Paul, the proposal looks
Paul,
Thanks for updating the KIP with the proposal. I do think the KIP should at
least mention that the prior behavior is to allow the worker to override
the `producer.client.id` or `consumer.client.id`, which is entirely
possible (though unlikely since there would be an MBean conflict, as
Randall, Paul, the proposal looks great, thanks.
Ryanne
On Mon, Mar 25, 2019, 9:03 AM Randall Hauch wrote:
> Paul,
>
> Thanks for updating the KIP with the proposal. I do think the KIP should at
> least mention that the prior behavior is to allow the worker to override
> the
Paul, Randall, I don't think most people will care to exercise so much
control over the client IDs, so long as they are filled in automatically in
a way that eliminates duplicate metrics and remains somewhat legible. If we
let the user specify a pattern or something, we're really just making the
Thanks Randall. I like your suggestion: as you say, this would make it
possible to usefully override the default client id properties.
I'm not sure how we would handle the dead-letter queue case though - maybe
we could automatically add a "dlq-" prefix to the producer client id?
If there is
Hi, Paul. Thanks for the update to KIP-411 to reflect adding defaults, and
creating/updating https://github.com/apache/kafka/pull/6097 to reflect this
approach.
Now that we've avoided adding a new config and have changed the default `
client.id` to include some context, the connector name, and
Thanks Paul, this is great. This will make monitoring Connect a ton easier.
Ryanne
On Wed, Feb 20, 2019 at 1:24 PM Paul Davidson
wrote:
> I have updated KIP-411 to propose changing the default client id - see:
>
>
I have updated KIP-411 to propose changing the default client id - see:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-411%3A+Make+default+Kafka+Connect+worker+task+client+IDs+distinct
There is also an PR ready to go here:
https://github.com/apache/kafka/pull/6097
On Fri, Jan 11, 2019 at
Hi everyone. We seem to have agreement that the ideal approach is to alter
the default client ids. Now I'm wondering about the best process to
proceed. Will the change in default behaviour require a new KIP, given it
will affect existing deployments? Would I be best to repurpose this
KIP-411, or
Hi, Paul.
I concur with the others, and I like the new approach that avoids a new
configuration, especially because it does not change the behavior for
anyone already using `producer.client.id` and/or `consumer.client.id`. I
did leave a few comments on the PR. Perhaps the biggest one is whether
Thanks all. I've submitted a new PR with a possible implementation:
https://github.com/apache/kafka/pull/6097. Note I did not include the group
ID as part of the default client ID, mainly to avoid the connector name
appearing twice by default. As noted in the original Jira (
I'd also prefer to avoid the new configuration property if possible. Seems
like a lighter touch without it.
Ryanne
On Sun, Jan 6, 2019 at 7:25 PM Paul Davidson
wrote:
> Hi Konstantine,
>
> Thanks for your feedback! I think my reply to Ewen covers most of your
> points, and I mostly agree. If
Hi Konstantine,
Thanks for your feedback! I think my reply to Ewen covers most of your
points, and I mostly agree. If there is general agreement that changing
the default behavior is preferable to a config change I will update my PR
to use that approach.
Paul
On Fri, Jan 4, 2019 at 5:55 PM
Hi Ewen,
Thanks for the feedback!
If that's the case, would it maybe be possible to compatibly change the
> default to use task IDs in the client ID, but only if we don't see an
> existing override from the worker config? This would only change the
> behavior when someone is using the default,
Hi Paul.
I second Ewen and I intended to give similar feedback:
1) Can we avoid a config altogether?
2) If we prefer to add a config anyways, can we use a set of allowed values
instead of a boolean, even if initially these values are only two? As the
discussion on Jira highlights, there is a
Hi Paul,
Thanks for the KIP. A few comments.
To me, biggest question here is if we can fix this behavior without adding
a config. In particular, today, we don't even set the client.id for the
producer and consumer at all, right? The *only* way it is set is if you
include an override in the
Hi everyone,
I would like to start a discussion around the following KIP:
*https://cwiki.apache.org/confluence/display/KAFKA/KIP-411%3A+Add+option+to+make+Kafka+Connect+task+client+ID+values+unique
21 matches
Mail list logo
