I think so, I'm +1 on this.
On Sat, Sep 15, 2018 at 8:14 AM Colin McCabe wrote:
> On Wed, Aug 15, 2018, at 05:04, Viktor Somogyi wrote:
> > Hi,
> >
> > To weigh-in, I agree with Colin on the API naming, overloads shouldn't
> > change behavior. I think all of the Java APIs I've used so far follow
On Wed, Aug 15, 2018, at 05:04, Viktor Somogyi wrote:
> Hi,
>
> To weigh-in, I agree with Colin on the API naming, overloads shouldn't
> change behavior. I think all of the Java APIs I've used so far followed
> this principle and I think we shouldn't diverge.
>
> Also I think I have an entry abou
Hi,
To weigh-in, I agree with Colin on the API naming, overloads shouldn't
change behavior. I think all of the Java APIs I've used so far followed
this principle and I think we shouldn't diverge.
Also I think I have an entry about this incremental thing in KIP-248. It
died off a bit at voting (I
I updated the KIP.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-339%3A+Create+a+new+IncrementalAlterConfigs+API
Updates:
* Use "incrementalAlterConfigs" rather than "modifyConfigs," for consistency
with the other "alter" APIs.
* Implement Magnus' idea of supporting "append" and "subtra
Hi Magnus,
Thanks for taking a look.
On Mon, Jul 16, 2018, at 11:43, Magnus Edenhill wrote:
> Thanks for driving this KIP, Colin.
>
> I agree with Dong that a new similar modifyConfigs API (and protocol API)
> is confusing and that
> we should try to extend the current alterConfigs interface to
Thanks for driving this KIP, Colin.
I agree with Dong that a new similar modifyConfigs API (and protocol API)
is confusing and that
we should try to extend the current alterConfigs interface to support the
incremental mode instead,
deprecating the non-incremental mode in the process.
Another thin
Hey Colin,
Thanks much for the explanation. Yeah it makes sense to deprecate the
existing non-incremental mode completely. LGTM. I just have two minor
comments.
I am not too strong with the following argument but it may be useful to
just put it here for discussion. I am still wondering whether we
On Fri, Jul 13, 2018, at 23:20, Dong Lin wrote:
> Hey Colin,
>
> Thanks for the KIP!
>
> It seems that the AlterConfigsResult is pretty much the same as
> ModifyConfigsResult. Instead of adding ModifyConfigs API and deprecating
> AlterConfigs API, would it be simpler to just add API alterConfigs(
Hey Colin,
Thanks for the KIP!
It seems that the AlterConfigsResult is pretty much the same as
ModifyConfigsResult. Instead of adding ModifyConfigs API and deprecating
AlterConfigs API, would it be simpler to just add API alterConfigs(
Map changes, Set removals, final
ModifyConfigsOptions options
I experimented with putting null value into ConcurrentHashMap which led me
to this code:
final V putVal(K key, V value, boolean onlyIfAbsent) {
if (key == null || value == null) throw new NullPointerException();
I agree that getting NPE this way is not user friendly.
Using Java 8, th
On Fri, Jul 13, 2018, at 17:45, Ted Yu wrote:
> Looking at modifyConfigs API, it doesn't seem that ConcurrentHashMap
> should be used as the underlying parameter type.
I agree that there are other types of maps that do support null values.
However, the fact that some official map implementations fr
Looking at modifyConfigs API, it doesn't seem that ConcurrentHashMap should
be used as the underlying parameter type.
Anyway, to signify that null value is supported, value type can be declared
as Optional.
FYI
On Fri, Jul 13, 2018 at 5:35 PM Colin McCabe wrote:
> Hi Ted,
>
> That’s a fair que
Hi Ted,
That’s a fair question. I think the main reason I didn’t propose that
originally is that many people find null values in maps confusing.
Also, some newer java maps don’t support null values, such as
ConcuurentHashMap. I’m curious what others think about this.
Best,
Colin
On Wed, Jul 11,
bq. Map changes, Set removals,
Is it possible to combine the two parameters into one Map where null Config
value signifies removal of config ?
This way, the following wouldn't occur (reducing un-intended config
removal):
bq. If a configuration key is specified in both *changes* and *removals*
Hi all,
Previously, we discussed some issues with alterConfigs here on the mailing
list, and eventually came to the conclusion that the RPC as implemented can't
be used for a shell command modifying configurations.
I wrote up a small KIP to fix the issues with the RPC. Please take a look at
h
15 matches
Mail list logo
