I would agree Jun
> On Feb 11, 2014, at 21:30, Jun Rao wrote:
>
> I actually think this is useful for non-LinkedIn users as well. The
> following is the tradeoff that I see.
>
> Most users probably won't care about seeing an extra 10-20 lines of INFO
> level logging when starting up a client. H
I actually think this is useful for non-LinkedIn users as well. The
following is the tradeoff that I see.
Most users probably won't care about seeing an extra 10-20 lines of INFO
level logging when starting up a client. However, it's very easy for users
to (1) mis-spell a config name (there was an
Yeah I am aware of how zookeeper behaves, I think it is kind of gross.
I think logging it at DEBUG gets you what you want--by default we don't
pollute logs, but anyone who wants to log this can enable DEBUG logging on
org.apache.kafka.clients.producer.ProducerConfig.
If we want this on by default
+1 Jun.
On Mon, Feb 10, 2014 at 2:17 PM, Sriram Subramanian <
srsubraman...@linkedin.com> wrote:
> +1 on Jun's suggestion.
>
> On 2/10/14 2:01 PM, "Jun Rao" wrote:
>
> >I actually prefer to see those at INFO level. The reason is that the
> >config
> >system in an application can be complex. Som
+1 on Jun's suggestion.
On 2/10/14 2:01 PM, "Jun Rao" wrote:
>I actually prefer to see those at INFO level. The reason is that the
>config
>system in an application can be complex. Some configs can be overridden in
>different layers and it may not be easy to determine what the final
>binding
>va
I actually prefer to see those at INFO level. The reason is that the config
system in an application can be complex. Some configs can be overridden in
different layers and it may not be easy to determine what the final binding
value is. The logging in Kafka will serve as the source of truth.
For r
Hey Jun,
I think that is reasonable but would object to having it be debug logging?
I think logging out a bunch of noise during normal operation in a client
library is pretty ugly. Also, is there value in exposing the final configs
programmatically?
-Jay
On Sun, Feb 9, 2014 at 9:23 PM, Jun Rao
+1 on the new config. Just one comment. Currently, when initiating a config
(e.g. ProducerConfig), we log those overridden property values and unused
property keys (likely due to mis-spelling). This has been very useful for
config verification. It would be good to add similar support in the new
con
Hey David,
Great questions.
The Configurable interface was meant to use with plugins. Originally we had
two of these in the producer, Serializer and Partitioner but we removed
them so now it is unused. However I think we will likely have several in
the consumer so I will leave it there for now. T
Jay, thanks for the clarification. I think I understand it a bit better
now, and It all pretty much makes sense. See inline
Also, slightly OT, but what are Configurable and
AbstractConfig#getConfiguredInstance for? I don't see anything using them.
On 2/6/14 11:46 AM, Jay Kreps wrote:
Hey Dav
Hey Guozhang,
You have to accept the boolean true to support convenient programmatic
configuration (the example I showed). You have to support taking a string
to allow injecting config from a config file or external application config
system. E.g. in the case where you supply a Properties instance
I made a typo in my previous email, I meant to say "not allowing", i.e. if
a config' type is Boolean, do not accept "true" as the value.
On Thu, Feb 6, 2014 at 8:30 AM, Jay Kreps wrote:
> Guozhang,
>
> In spirit I agree with you, but it is really annoying if I can't say
>props.put("config.a
Hey David,
You raise a couple points, let me give the rationale and see if you are
convinced.
1. Why not reuse commons config? This is exactly the right question for
application programming. We could save ourselves a few hundred lines of
code we would maintain by just adding a library dependency,
Joel,
Ah, I actually don't think the internal usage is a problem for *us*. We
just use config in one place, whereas it gets set in 1000s of apps, so I am
implicitly optimizing for the application interface. I agree that we can
add getters and setters on the ProducerConfig if we like. Basically I w
Guozhang,
In spirit I agree with you, but it is really annoying if I can't say
props.put("config.a", 45)
props.put("config.b", true)
This is especially true because config will actually come from elsewhere
and may have the appropriate type so in reality you end up with
props.put("config.
The declarative approach strikes me as a bit odd. Why not put the
precondition logic in a POJO wrapper? Also, why reinvent
commons-configuration? It's got a nice API and tons of people use it.
public class ProducerConfig extends org.apache.commons.configuration.
AbstractConfiguration {
/**
I like the helper function in all except in parseType: is it better to be
restrict about types, i.e. now allowing "true" if the type is really
Boolean?
On Wed, Feb 5, 2014 at 5:06 PM, Joel Koshy wrote:
> Overall, +1 on sticking with key-values for configs.
>
>
> > Con: The IDE gives nice auto-c
Overall, +1 on sticking with key-values for configs.
> Con: The IDE gives nice auto-completion for pojos.
>
> Con: There are some advantages to javadoc as a documentation mechanism for
> java people.
Optionally, both the above cons can be addressed (to some degree) by
wrapper config POJOs that
We touched on this a bit in previous discussions, but I wanted to draw out
the approach to config specifically as an item of discussion.
The new producer and consumer use a similar key-value config approach as
the existing scala clients but have different implementation code to help
define these c
19 matches
Mail list logo
