Jenkins build is back to normal : kafka-trunk-jdk10 #18

[Apache Jenkins Server]

See 

[jira] [Created] (KAFKA-6792) Wrong pointer in the link for stream dsl

[robin m (JIRA)]

robin m created KAFKA-6792:
--

 Summary: Wrong pointer in the link for stream dsl
 Key: KAFKA-6792
 URL: https://issues.apache.org/jira/browse/KAFKA-6792
 Project: Kafka
  Issue Type: Bug
Reporter: robin m


Wrong pointer in the link for stream dsl.

actual is : 
[http://kafka.apache.org/11/documentation/streams/developer-guide#streams|http://kafka.apache.org/11/documentation/streams/developer-guide/#streams]_dsl

correct is : 
http://kafka.apache.org/11/documentation/streams/developer-guide/dsl-api.html#streams-dsl



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] KIP-265: Make Windowed Serde to public APIs

[Guozhang Wang]

Hello folks,

I have updated KIP-265 a bit on the window serde configuration logic, based
on the decisions we made during the implementation of the two JIRAs. Please
feel free to read the updated wiki page:

https://cwiki.apache.org/confluence/display/KAFKA/KIP-265%3A+Make+Windowed+Serde+to+public+APIs

Guozhang

On Thu, Mar 8, 2018 at 1:25 PM, Guozhang Wang  wrote:

> +1 from myself as well.
>
>
> I'm closing the vote for KIP-265 with the following results:
>
> binding +1: Matthias, Damian, Guozhang
> non-binding +1: Xi, Ted, Bill
>
>
> Thanks everyone for the votes.
>
>
> Guozhang
>
>
> On Thu, Mar 8, 2018 at 11:18 AM, Damian Guy  wrote:
>
>> Thanks Guozhang +1
>>
>> On Tue, 6 Mar 2018 at 00:26 Hu Xi  wrote:
>>
>> > +1 (non-binding)
>> >
>> > 
>> > 发件人: Matthias J. Sax 
>> > 发送时间: 2018年3月6日 8:19
>> > 收件人: dev@kafka.apache.org
>> > 主题: Re: [VOTE] KIP-265: Make Windowed Serde to public APIs
>> >
>> > +1 (binding)
>> >
>> > Thanks for the KIP Guozhang!
>> >
>> > -Matthias
>> >
>> > On 3/5/18 2:41 PM, Bill Bejeck wrote:
>> > > Thanks for the KIP Guozhang.
>> > >
>> > > +1
>> > >
>> > > -Bill
>> > >
>> > > On Mon, Mar 5, 2018 at 5:11 PM, Ted Yu  wrote:
>> > >
>> > >> +1
>> > >>
>> > >> On Mon, Mar 5, 2018 at 1:46 PM, Guozhang Wang 
>> > wrote:
>> > >>
>> > >>> Hello all,
>> > >>>
>> > >>> I'd like to start voting on KIP-265, on making windowed serde to
>> public
>> > >>> APIs of Kafka Streams. It involves a couple of new configs, plus a
>> few
>> > >> new
>> > >>> public classes for windowed serializer and deserializer, and also
>> > adding
>> > >>> the corresponding console consumer options in order to fetch from a
>> > topic
>> > >>> written by a windowed store.
>> > >>>
>> > >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
>> > >>> 265%3A+Make+Windowed+Serde+to+public+APIs
>> > >>>
>> > >>>
>> > >>>
>> > >>> Thanks,
>> > >>> -- Guozhang
>> > >>>
>> > >>
>> > >
>> >
>> >
>>
>
>
>
> --
> -- Guozhang
>



-- 
-- Guozhang

[jira] [Resolved] (KAFKA-6531) SocketServerTest#closingChannelException fails sometimes

[Ted Yu (JIRA)]

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

Ted Yu resolved KAFKA-6531.
---
Resolution: Cannot Reproduce

> SocketServerTest#closingChannelException fails sometimes
> 
>
> Key: KAFKA-6531
> URL: https://issues.apache.org/jira/browse/KAFKA-6531
> Project: Kafka
>  Issue Type: Test
>  Components: core
>Reporter: Ted Yu
>Priority: Minor
>
> From 
> https://builds.apache.org/job/kafka-trunk-jdk9/361/testReport/junit/kafka.network/SocketServerTest/closingChannelException/
>  :
> {code}
> java.lang.AssertionError: Channels not removed
>   at kafka.utils.TestUtils$.fail(TestUtils.scala:355)
>   at kafka.utils.TestUtils$.waitUntilTrue(TestUtils.scala:865)
>   at 
> kafka.network.SocketServerTest.assertProcessorHealthy(SocketServerTest.scala:914)
>   at 
> kafka.network.SocketServerTest.$anonfun$closingChannelException$1(SocketServerTest.scala:763)
>   at 
> kafka.network.SocketServerTest.$anonfun$closingChannelException$1$adapted(SocketServerTest.scala:747)
> {code}
> Among the test output, I saw:
> {code}
> [2018-02-04 18:51:15,995] ERROR Processor 0 closed connection from 
> /127.0.0.1:48261 (kafka.network.SocketServerTest$$anon$5$$anon$1:73)
> java.lang.IllegalStateException: There is already a connection for id 
> 127.0.0.1:1-127.0.0.1:2-0
>   at 
> org.apache.kafka.common.network.Selector.ensureNotRegistered(Selector.java:260)
>   at org.apache.kafka.common.network.Selector.register(Selector.java:254)
>   at 
> kafka.network.SocketServerTest$TestableSelector.super$register(SocketServerTest.scala:1043)
>   at 
> kafka.network.SocketServerTest$TestableSelector.$anonfun$register$2(SocketServerTest.scala:1043)
>   at 
> scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:12)
>   at 
> kafka.network.SocketServerTest$TestableSelector.runOp(SocketServerTest.scala:1037)
>   at 
> kafka.network.SocketServerTest$TestableSelector.register(SocketServerTest.scala:1043)
>   at 
> kafka.network.Processor.configureNewConnections(SocketServer.scala:723)
>   at kafka.network.Processor.run(SocketServer.scala:532)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Jenkins build is back to normal : kafka-trunk-jdk8 #2550

[Apache Jenkins Server]

See 

Re: [VOTE] KIP-279: Fix log divergence between leader and follower after fast leader fail over

[Damian Guy]

Thanks Anna +1
On Sun, 15 Apr 2018 at 15:40, Guozhang Wang  wrote:

> Anna, thanks for the KIP! +1 from me.
>
> Just one minor comment: `Broker A will respond with offset 11`, seems it
> should be `21`.
>
> On Sun, Apr 15, 2018 at 3:48 AM, Dong Lin  wrote:
>
> > Thanks for the KIP! LGTM. +1
> >
> > On Sat, Apr 14, 2018 at 5:31 PM, Ted Yu  wrote:
> >
> > > +1
> > >
> > > On Sat, Apr 14, 2018 at 3:54 PM, Anna Povzner 
> wrote:
> > >
> > > > Hi All,
> > > >
> > > >
> > > > I would like to start the vote on KIP-279: Fix log divergence between
> > > > leader and follower after fast leader fail over.
> > > >
> > > >
> > > > For reference, here's the KIP wiki:
> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > 279%3A+Fix+log+divergence+between+leader+and+follower+
> > > > after+fast+leader+fail+over
> > > >
> > > >
> > > >
> > > > and discussion thread:
> > > > https://www.mail-archive.com/dev@kafka.apache.org/msg86753.html
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Anna
> > > >
> > >
> >
>
>
>
> --
> -- Guozhang
>

Re: [DISCUSS] KIP-276: Add StreamsConfig prefix for different consumers

[Boyang Chen]

Hey Ewen,


in case you don't have any further concern, I shall move this KIP to the voting 
stage. Let me know your thoughts.


Thank you!



From: Boyang Chen 
Sent: Sunday, April 15, 2018 4:25 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-276: Add StreamsConfig prefix for different consumers


Thank you Guozhang for the explanation. Ewen, I think your concern has been 
addressed, do you want share any further concern on this KIP?


Thank you!


From: Guozhang Wang 
Sent: Friday, April 13, 2018 12:34 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-276: Add StreamsConfig prefix for different consumers

Thanks Ewen and Matthias for the explanation. I'm also in favor of the
current proposal, and my rationale are basically 1) inheritance hierarchy
is simple for users to understand (Matthias has explained it well), 2) for
normal users they only need to have the base consumer configs specification.

Ewen raised a valid point though, that if users mistakenly specifies the
wrong overridden values it is a bit hard to debug and find out why
something's not working, e.g. for security. My experience is that printing
the config values for different embedded clients does help a lot in those
cases, so maybe we can double check on in StreamsConfig to make sure before
the clients are initialized we do print their config values (the full
property map).


Guozhang

On Wed, Apr 11, 2018 at 7:22 PM, Boyang Chen  wrote:

> Thanks Ewen for sharing your concern in the inheritance, and Matthias for
> the explanation to each bullet point.
>
>
> I'm not super expert on security, so I would like to explain why I took
> over this Jira in the first place, i.e. the use case. Our stream
> application requires millisecond delay guarantee and has to be brought back
> to normal when restarting within 5 minutes. The current bottleneck is that
> when restoring the state, `max.poll.record` config is shared between main
> consumer and restore consumer, and there is a certain limit of the main
> consumer capability to process data. This way, we want to fully unblock
> restore consumer capability as it is not required to do heavy computation.
> By overriding the config, restore consumer could poll 2-3X faster which is
> the right solution to the use case here. This is exactly the case Matthias
> has mentioned in the previous email, hope this helps!
>
>
> Best,
>
> Boyang
>
>
> 
> From: Matthias J. Sax 
> Sent: Thursday, April 12, 2018 8:35 AM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-276: Add StreamsConfig prefix for different
> consumers
>
> Thanks for the explanation.
>
> I am not sure if I follow your objection about inheritance. Basically,
> every config that is not overwritten inherits the default setting -- so
> there is actually already a hierarchy in place from my point of view.
>
> With regard to security config, I guess the issue is, that it's not one
> parameter, but multiple and if you only overwrite some but not others
> you end up with a bad config -- for this case, my personal
> recommendation would be, to not use the base config but put a specific
> config for each client to avoid confusion. However, most configs are
> "single parameter" configs and I don't see any issue for those with
> regard to inheritance.
>
> About your proposal, you basically say the following: if for any client,
> at least one client specific config is set (eg, restore.consumer.X),
> even if base configs aare specified (consumer.A and consumer.B), the
> restore consumer should only set restore.consumer.X and use the default
> for config A and B and ignore consumer.A and consumer.B setting? While I
> understand why your argue for this, it does not seem to be intuitive.
> It's basically a conditional inheritance and maybe even more complex
> that what the KIP proposes?
>
> Having said this, if we follow your proposal, it might even be better to
> do a more radical change and drop inheritance completely. Ie, config `X`
> would be ignored (if it's not a Streams Config), and users need to
> prefix it for all cases with either `producer.`, `main.consumer.`,
> `restore.consumer.`, or `global.consumer`.
>
> We could introduce this, however, it breaks the current pattern, because
> inheritance is already in place. For configs that are common for
> producer and consumer (for example `request.timeout.ms`) today users can
> specify the following:
>
> request.timeout.ms=X
> consumer.request.timeout.ms=Y
> producer.retries=Z
>
> With this, producer set both `request.timeout` as well as `retries`.
>
> If we adapt your suggestion we make a backward incompatible change.
> Thus, only if we feel strong about your argument (it has a valid concern
> about configs with multiple parameters) we should change the behavior
> from my point of view. The KIP only introduce one more level in the
> hierarchy.
>
>
> The last point:
>
> >> Why? what are those use 

Build failed in Jenkins: kafka-trunk-jdk8 #2549

[Apache Jenkins Server]

See 


Changes:

[wangguoz] KAFKA-6790: Fix Streams processor node broken link (#4874)

--
[...truncated 3.53 MB...]

kafka.zookeeper.ZooKeeperClientTest > testPipelinedGetData STARTED

kafka.zookeeper.ZooKeeperClientTest > testPipelinedGetData PASSED

kafka.zookeeper.ZooKeeperClientTest > testZNodeChildChangeHandlerForChildChange 
STARTED

kafka.zookeeper.ZooKeeperClientTest > testZNodeChildChangeHandlerForChildChange 
PASSED

kafka.zookeeper.ZooKeeperClientTest > testGetChildrenExistingZNodeWithChildren 
STARTED

kafka.zookeeper.ZooKeeperClientTest > testGetChildrenExistingZNodeWithChildren 
PASSED

kafka.zookeeper.ZooKeeperClientTest > testSetDataExistingZNode STARTED

kafka.zookeeper.ZooKeeperClientTest > testSetDataExistingZNode PASSED

kafka.zookeeper.ZooKeeperClientTest > testMixedPipeline STARTED

kafka.zookeeper.ZooKeeperClientTest > testMixedPipeline PASSED

kafka.zookeeper.ZooKeeperClientTest > testGetDataExistingZNode STARTED

kafka.zookeeper.ZooKeeperClientTest > testGetDataExistingZNode PASSED

kafka.zookeeper.ZooKeeperClientTest > testDeleteExistingZNode STARTED

kafka.zookeeper.ZooKeeperClientTest > testDeleteExistingZNode PASSED

kafka.zookeeper.ZooKeeperClientTest > testSessionExpiry STARTED

kafka.zookeeper.ZooKeeperClientTest > testSessionExpiry PASSED

kafka.zookeeper.ZooKeeperClientTest > testSetDataNonExistentZNode STARTED

kafka.zookeeper.ZooKeeperClientTest > testSetDataNonExistentZNode PASSED

kafka.zookeeper.ZooKeeperClientTest > testDeleteNonExistentZNode STARTED

kafka.zookeeper.ZooKeeperClientTest > testDeleteNonExistentZNode PASSED

kafka.zookeeper.ZooKeeperClientTest > testExistsExistingZNode STARTED

kafka.zookeeper.ZooKeeperClientTest > testExistsExistingZNode PASSED

kafka.zookeeper.ZooKeeperClientTest > testZooKeeperStateChangeRateMetrics 
STARTED

kafka.zookeeper.ZooKeeperClientTest > testZooKeeperStateChangeRateMetrics PASSED

kafka.zookeeper.ZooKeeperClientTest > testZNodeChangeHandlerForDeletion STARTED

kafka.zookeeper.ZooKeeperClientTest > testZNodeChangeHandlerForDeletion PASSED

kafka.zookeeper.ZooKeeperClientTest > testGetAclNonExistentZNode STARTED

kafka.zookeeper.ZooKeeperClientTest > testGetAclNonExistentZNode PASSED

kafka.zookeeper.ZooKeeperClientTest > testStateChangeHandlerForAuthFailure 
STARTED

kafka.zookeeper.ZooKeeperClientTest > testStateChangeHandlerForAuthFailure 
PASSED

kafka.network.SocketServerTest > testGracefulClose STARTED

kafka.network.SocketServerTest > testGracefulClose PASSED

kafka.network.SocketServerTest > controlThrowable STARTED

kafka.network.SocketServerTest > controlThrowable PASSED

kafka.network.SocketServerTest > testRequestMetricsAfterStop STARTED

kafka.network.SocketServerTest > testRequestMetricsAfterStop PASSED

kafka.network.SocketServerTest > testConnectionIdReuse STARTED

kafka.network.SocketServerTest > testConnectionIdReuse PASSED

kafka.network.SocketServerTest > testClientDisconnectionUpdatesRequestMetrics 
STARTED

kafka.network.SocketServerTest > testClientDisconnectionUpdatesRequestMetrics 
PASSED

kafka.network.SocketServerTest > testProcessorMetricsTags STARTED

kafka.network.SocketServerTest > testProcessorMetricsTags PASSED

kafka.network.SocketServerTest > testMaxConnectionsPerIp STARTED

kafka.network.SocketServerTest > testMaxConnectionsPerIp PASSED

kafka.network.SocketServerTest > testConnectionId STARTED

kafka.network.SocketServerTest > testConnectionId PASSED

kafka.network.SocketServerTest > 
testBrokerSendAfterChannelClosedUpdatesRequestMetrics STARTED

kafka.network.SocketServerTest > 
testBrokerSendAfterChannelClosedUpdatesRequestMetrics PASSED

kafka.network.SocketServerTest > testNoOpAction STARTED

kafka.network.SocketServerTest > testNoOpAction PASSED

kafka.network.SocketServerTest > simpleRequest STARTED

kafka.network.SocketServerTest > simpleRequest PASSED

kafka.network.SocketServerTest > closingChannelException STARTED

kafka.network.SocketServerTest > closingChannelException PASSED

kafka.network.SocketServerTest > testIdleConnection STARTED

kafka.network.SocketServerTest > testIdleConnection PASSED

kafka.network.SocketServerTest > 
testClientDisconnectionWithStagedReceivesFullyProcessed STARTED

kafka.network.SocketServerTest > 
testClientDisconnectionWithStagedReceivesFullyProcessed PASSED

kafka.network.SocketServerTest > testZeroMaxConnectionsPerIp STARTED

kafka.network.SocketServerTest > testZeroMaxConnectionsPerIp PASSED

kafka.network.SocketServerTest > testMetricCollectionAfterShutdown STARTED

kafka.network.SocketServerTest > testMetricCollectionAfterShutdown PASSED

kafka.network.SocketServerTest > testSessionPrincipal STARTED

kafka.network.SocketServerTest > testSessionPrincipal PASSED

kafka.network.SocketServerTest > configureNewConnectionException STARTED

kafka.network.SocketServerTest > configureNewConnectionException PASSED

kafka.network.So

Jenkins build is back to normal : kafka-trunk-jdk7 #3338

[Apache Jenkins Server]

See 

Build failed in Jenkins: kafka-trunk-jdk10 #17

[Apache Jenkins Server]

See 


Changes:

[github] KAFKA-6058: Refactor consumer API result return types (#4856)

[github] KAFKA-6611, PART II: Improve Streams SimpleBenchmark (#4854)

--
[...truncated 1.78 MB...]
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:42)
at 
org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:230)
at 
org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:149)
at 
org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:58)
at 
org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:324)
at 
org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:234)
at 
org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:140)
at 
org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:37)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy79.output(Unknown Source)
at 
org.gradle.api.internal.tasks.testing.results.StateTrackingTestResultProcessor.output(StateTrackingTestResultProcessor.java:87)
at 
org.gradle.api.internal.tasks.testing.results.AttachParentTestResultProcessor.output(AttachParentTestResultProcessor.java:48)
at jdk.internal.reflect.GeneratedMethodAccessor292.invoke(Unknown 
Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.FailureHandlingDispatch.dispatch(FailureHandlingDispatch.java:29)
at 
org.gradle.internal.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:133)
at 
org.gradle.internal.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:34)
at 
org.gradle.internal.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:73)
at 
org.gradle.internal.operations.BuildOperationIdentifierPreservingRunnable.run(BuildOperationIdentifierPreservingRunnable.java:39)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at 
org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at 
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.io.IOException: No space left on device
at java.base/java.io.FileOutputStream.writeBytes(Native Method)
at java.base/java.io.FileOutputStream.write(FileOutputStream.java:355)
at com.esotericsoftware.kryo.io.Output.flush(Output.java:154)
... 54 more
java.io.IOException: No space left on device
com.esotericsoftware.kryo.KryoException: java.io.IOException: No space left on 
device
at com.esotericsoftware.kryo.io.Output.flush(Output.java:156)
at com.esotericsoftware.kryo.io.Output.require(Output.java:134)
at com.esotericsoftware.kryo.io.Output.writeBoolean(Output.java:578)
at 
org.gradle.internal.serialize.kryo.KryoBackedEncoder.writeBoolean(KryoBackedEncoder.java:63)
at 
org.gradle.api.internal.tasks.testing.junit.result.TestOutputStore$Writer.onOutput(TestOutputStore.java:99)
at 
org.gradle.api.internal.tasks.testing.junit.result.TestReportDataCollector.onOutput(TestReportDataCollector.java:141)
at jdk.internal.reflect.GeneratedMethodAccessor291.invoke(Unknown 
Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(Abst

Build failed in Jenkins: kafka-trunk-jdk10 #16

[Apache Jenkins Server]

See 


Changes:

[wangguoz] KAFKA-6790: Fix Streams processor node broken link (#4874)

--
[...truncated 1.65 MB...]
at 
org.gradle.api.internal.tasks.testing.results.TestListenerAdapter.output(TestListenerAdapter.java:56)
at jdk.internal.reflect.GeneratedMethodAccessor289.invoke(Unknown 
Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:42)
at 
org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:230)
at 
org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:149)
at 
org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:58)
at 
org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:324)
at 
org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:234)
at 
org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:140)
at 
org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:37)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy79.output(Unknown Source)
at 
org.gradle.api.internal.tasks.testing.results.StateTrackingTestResultProcessor.output(StateTrackingTestResultProcessor.java:87)
at 
org.gradle.api.internal.tasks.testing.results.AttachParentTestResultProcessor.output(AttachParentTestResultProcessor.java:48)
at jdk.internal.reflect.GeneratedMethodAccessor292.invoke(Unknown 
Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.FailureHandlingDispatch.dispatch(FailureHandlingDispatch.java:29)
at 
org.gradle.internal.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:133)
at 
org.gradle.internal.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:34)
at 
org.gradle.internal.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:73)
at 
org.gradle.internal.operations.BuildOperationIdentifierPreservingRunnable.run(BuildOperationIdentifierPreservingRunnable.java:39)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at 
org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at 
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.io.IOException: No space left on device
at java.base/java.io.FileOutputStream.writeBytes(Native Method)
at java.base/java.io.FileOutputStream.write(FileOutputStream.java:355)
at com.esotericsoftware.kryo.io.Output.flush(Output.java:154)
... 54 more
java.io.IOException: No space left on device
com.esotericsoftware.kryo.KryoException: java.io.IOException: No space left on 
device
at com.esotericsoftware.kryo.io.Output.flush(Output.java:156)
at com.esotericsoftware.kryo.io.Output.require(Output.java:134)
at com.esotericsoftware.kryo.io.Output.writeBoolean(Output.java:578)
at 
org.gradle.internal.serialize.kryo.KryoBackedEncoder.writeBoolean(KryoBackedEncoder.java:63)
at 
org.gradle.api.internal.tasks.testing.junit.result.TestOutputStore$Writer.onOutput(TestOutputStore.java:99)
at 
org.gradle.api.internal.tasks.testing.junit.result.TestReportDataCollector.onOutput(TestReportDataCollector.java:141)
at jdk.internal.reflect.GeneratedMethodAccessor291.invoke(Unknown 
Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.gradle.intern

[jira] [Resolved] (KAFKA-6058) KIP-222: Add "describe consumer groups" and "list consumer groups" to KafkaAdminClient

[Guozhang Wang (JIRA)]

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

Guozhang Wang resolved KAFKA-6058.
--
Resolution: Fixed

> KIP-222: Add "describe consumer groups" and "list consumer groups" to 
> KafkaAdminClient
> --
>
> Key: KAFKA-6058
> URL: https://issues.apache.org/jira/browse/KAFKA-6058
> Project: Kafka
>  Issue Type: Improvement
>  Components: clients
>Reporter: Matthias J. Sax
>Assignee: Jorge Quilcate
>Priority: Major
>  Labels: kip-222
> Fix For: 1.2.0
>
>
> {{KafkaAdminClient}} does not allow to get information about consumer groups. 
> This feature is supported by old {{kafka.admin.AdminClient}} though.
> We should add {{KafkaAdminClient#describeConsumerGroups()}} and 
> {{KafkaAdminClient#listConsumerGroup()}}.
> Associated KIP: KIP-222



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] KIP-222 - Add "describe consumer group" to KafkaAdminClient

[Guozhang Wang]

Hello folks,

I have update the KIP-222 wiki slightly upon the discussions we had during
the implementations of the KIP. Please find more information on the
following PRs:

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

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


Guozhang

On Tue, Feb 6, 2018 at 2:33 PM, Jorge Esteban Quilcate Otoya <
quilcate.jo...@gmail.com> wrote:

> Thanks Matthias. I have updated the version on KIP main page also.
>
> There are some changes that arise on the Pull Request. I will comment them
> on the discussion thread.
>
> Cheers,
> Jorge.
>
> El vie., 2 feb. 2018 a las 20:50, Matthias J. Sax ( >)
> escribió:
>
> > Feature freeze for 1.1 passed already, thus, KIP-222 will not be part of
> > 1.1 release.
> >
> > I updated the JIRA with target version 1.2.
> >
> > -Matthias
> >
> > On 2/1/18 3:57 PM, Jeff Widman wrote:
> > > Don't forget to update the wiki page now that the vote has passed--it
> > > currently says this KIP is "under discussion":
> > >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 222+-+Add+Consumer+Group+operations+to+Admin+API
> > >
> > > Also, should the JIRA ticket be tagged with 1.1.0 (provided this is
> > merged
> > > by then)?
> > >
> > > On Mon, Jan 22, 2018 at 3:26 AM, Jorge Esteban Quilcate Otoya <
> > > quilcate.jo...@gmail.com> wrote:
> > >
> > >> My bad, KIP is updated:
> > >>
> > >> ```
> > >> public class MemberDescription {
> > >> private final String consumerId;
> > >> private final String clientId;
> > >> private final String host;
> > >> private final MemberAssignment assignment;
> > >> }
> > >> public class MemberAssignment {
> > >> private final List assignment;
> > >> }
> > >> ```
> > >>
> > >> Cheers,
> > >> Jorge.
> > >>
> > >> El lun., 22 ene. 2018 a las 6:46, Jun Rao ()
> > escribió:
> > >>
> > >>> Hi, Jorge,
> > >>>
> > >>> For #3, I wasn't suggesting using the internal Assignment. We can
> just
> > >>> introduce a new public type that wraps List. We can
> > call
> > >> it
> > >>> sth like MemberAssignment to distinguish it from the internal one.
> This
> > >>> makes extending the type in the future easier.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Jun
> > >>>
> > >>> On Sun, Jan 21, 2018 at 3:19 PM, Jorge Esteban Quilcate Otoya <
> > >>> quilcate.jo...@gmail.com> wrote:
> > >>>
> >  Hi all,
> > 
> >  Thanks all for your votes and approving this KIP :)
> > 
> >  @Jun Rao:
> > 
> >  1. Yes, KIP is updated with MemberDescription.
> >  2. Changed:
> >  ```
> >  public class ListGroupOffsetsResult {
> >  final KafkaFuture>
> future;
> >  ```
> >  3. Not sure about this one as Assignment type is part of
> >  o.a.k.clients.consumer.internals. Will we be breaking encapsulation
> > >> if we
> >  expose it as part of AdminClient?
> >  Currently is defined as:
> >  ```
> >  public class MemberDescription {
> >  private final String consumerId;
> >  private final String clientId;
> >  private final String host;
> >  private final List assignment;
> >  }
> >  ```
> > 
> >  BTW: I've created a PR with the work in progress:
> >  https://github.com/apache/kafka/pull/4454
> > 
> >  Cheers,
> >  Jorge.
> > 
> >  El vie., 19 ene. 2018 a las 23:52, Jun Rao ()
> > >>> escribió:
> > 
> > > Hi, Jorge,
> > >
> > > Thanks for the KIP. Looks good to me overall. A few comments below.
> > >
> > > 1. It seems that ConsumerDescription should be MemberDescription?
> > >
> > > 2. Each offset can have an optional metadata. So, in
> > > ListGroupOffsetsResult, perhaps it's better to have
> > > KafkaFuture>, where
> > > OffsetAndMetadata contains an offset and a metadata of String.
> > >
> > > 3. As Jason mentioned in the discussion, it would be nice to extend
> > >>> this
> > > api to support general group management, instead of just the
> consumer
> >  group
> > > in the future. For that, it might be better for MemberDescription
> to
> > >>> have
> > > assignment of type Assignment, which consists of a list of
> > >> partitions.
> > > Then, in the future, we can add other fields to Assignment.
> > >
> > > Jun
> > >
> > >
> > > On Thu, Jan 18, 2018 at 9:45 AM, Mickael Maison <
> >  mickael.mai...@gmail.com>
> > > wrote:
> > >
> > >> +1 (non binding), thanks
> > >>
> > >> On Thu, Jan 18, 2018 at 5:41 PM, Colin McCabe  >
> > > wrote:
> > >>> +1 (non-binding)
> > >>>
> > >>> Colin
> > >>>
> > >>>
> > >>> On Thu, Jan 18, 2018, at 07:36, Ted Yu wrote:
> >  +1
> >   Original message From: Bill Bejeck <
> > > bbej...@gmail.com>
> >  Date: 1/18/18  6:59 AM  (GMT-08:00) To: dev@kafka.apache.org
> >  Subject:
> >  Re: [VOTE] KIP-222 - Add "describe consumer group" to
> >  KafkaAdminClient
> >  Thanks for 

[jira] [Resolved] (KAFKA-6790) Broken link in documentation for processor nodes

[Guozhang Wang (JIRA)]

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

Guozhang Wang resolved KAFKA-6790.
--
   Resolution: Fixed
Fix Version/s: 1.1.0

> Broken link in documentation for processor nodes
> 
>
> Key: KAFKA-6790
> URL: https://issues.apache.org/jira/browse/KAFKA-6790
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Reporter: robin m
>Priority: Major
> Fix For: 1.1.0
>
>
> The page here 
> [https://kafka.apache.org/11/documentation/streams/developer-guide/memory-mgmt.html]
>  talks about processor nodes and refers to non existing links.
> Broken link (appears twice in the same document):
> [https://kafka.apache.org/11/documentation/streams/concepts.html#streams-concepts-processor]
> To find this search for the word "processor node" on the page 
> memory-management , the ones which are links are broken.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (KAFKA-6791) Add a CoordinatorNodeProvider in KafkaAdminClient

[Guozhang Wang (JIRA)]

Guozhang Wang created KAFKA-6791:


 Summary: Add a CoordinatorNodeProvider in KafkaAdminClient
 Key: KAFKA-6791
 URL: https://issues.apache.org/jira/browse/KAFKA-6791
 Project: Kafka
  Issue Type: Improvement
  Components: admin
Reporter: Guozhang Wang


As we add more and more coordinator-related requests to the admin client, we 
can consider adding a CoordinatorNodeProvider to consolidate the common logic 
pattern of finding the coordinator first, then send the corresponding request.

Note that 1) with this provider interface it is almost not possible to batch 
multiple groupIds per coordinator; there has to be a little more refactoring to 
make it work. 2) for some requests like list consumers, group ids are not known 
beforehand and hence we cannot use this provider as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] KIP-279: Fix log divergence between leader and follower after fast leader fail over

[Guozhang Wang]

Anna, thanks for the KIP! +1 from me.

Just one minor comment: `Broker A will respond with offset 11`, seems it
should be `21`.

On Sun, Apr 15, 2018 at 3:48 AM, Dong Lin  wrote:

> Thanks for the KIP! LGTM. +1
>
> On Sat, Apr 14, 2018 at 5:31 PM, Ted Yu  wrote:
>
> > +1
> >
> > On Sat, Apr 14, 2018 at 3:54 PM, Anna Povzner  wrote:
> >
> > > Hi All,
> > >
> > >
> > > I would like to start the vote on KIP-279: Fix log divergence between
> > > leader and follower after fast leader fail over.
> > >
> > >
> > > For reference, here's the KIP wiki:
> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > 279%3A+Fix+log+divergence+between+leader+and+follower+
> > > after+fast+leader+fail+over
> > >
> > >
> > >
> > > and discussion thread:
> > > https://www.mail-archive.com/dev@kafka.apache.org/msg86753.html
> > >
> > >
> > > Thanks,
> > >
> > > Anna
> > >
> >
>



-- 
-- Guozhang

Re: [VOTE] KIP-279: Fix log divergence between leader and follower after fast leader fail over

[Dong Lin]

Thanks for the KIP! LGTM. +1

On Sat, Apr 14, 2018 at 5:31 PM, Ted Yu  wrote:

> +1
>
> On Sat, Apr 14, 2018 at 3:54 PM, Anna Povzner  wrote:
>
> > Hi All,
> >
> >
> > I would like to start the vote on KIP-279: Fix log divergence between
> > leader and follower after fast leader fail over.
> >
> >
> > For reference, here's the KIP wiki:
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 279%3A+Fix+log+divergence+between+leader+and+follower+
> > after+fast+leader+fail+over
> >
> >
> >
> > and discussion thread:
> > https://www.mail-archive.com/dev@kafka.apache.org/msg86753.html
> >
> >
> > Thanks,
> >
> > Anna
> >
>

Re: [VOTE] #2 KIP-248: Create New ConfigCommand That Uses The New AdminClient

[Ted Yu]

+1
 Original message From: zhenya Sun  Date: 
4/15/18  12:42 AM  (GMT-08:00) To: dev  Cc: dev 
 Subject: Re: [VOTE] #2 KIP-248: Create New ConfigCommand 
That Uses The New AdminClient 
non-binding +1





from my iphone！
On 04/15/2018 15:41, Attila Sasvári wrote:
Thanks for updating the KIP.

+1 (non-binding)

Viktor Somogyi  ezt írta (időpont: 2018. ápr. 9.,
H 16:49):

> Hi Magnus,
>
> Thanks for the heads up, added the endianness to the KIP. Here is the
> current text:
>
> "Double
> A new type needs to be added to transfer quota values. Since the protocol
> classes in Kafka already uses ByteBuffers it is logical to use their
> functionality for serializing doubles. The serialization is basically a
> representation of the specified floating-point value according to the IEEE
> 754 floating-point "double format" bit layout. The ByteBuffer serializer
> writes eight bytes containing the given double value, in Big Endian byte
> order, into this buffer at the current position, and then increments the
> position by eight.
>
> The implementation will be defined in
> org.apache.kafka.common.protocol.types with the other protocol types and it
> will have no default value much like the other types available in the
> protocol."
>
> Also, I haven't changed the protocol docs yet but will do so in my PR for
> this feature.
>
> Let me know if you'd still add something.
>
> Regards,
> Viktor
>
>
> On Mon, Apr 9, 2018 at 3:32 PM, Magnus Edenhill 
> wrote:
>
> > Hi Viktor,
> >
> > since serialization of floats isn't as straight forward as integers,
> please
> > specify the exact serialization format of DOUBLE in the protocol docs
> > (e.g., IEEE 754),
> > including endianness (big-endian please).
> >
> > This will help the non-java client ecosystem.
> >
> > Thanks,
> > Magnus
> >
> >
> > 2018-04-09 15:16 GMT+02:00 Viktor Somogyi :
> >
> > > Hi Attila,
> > >
> > > 1. It uses ByteBuffers, which in turn will use Double.doubleToLongBits
> to
> > > convert the double value to a long and that long will be written in the
> > > buffer. I'v updated the KIP with this.
> > > 2. Good idea, modified it.
> > > 3. During the discussion I remember we didn't really decide which one
> > would
> > > be the better one but I agree that a wrapper class that makes sure the
> > list
> > > that is used as a key is immutable is a good idea and would ease the
> life
> > > of people using the interface. Also more importantly would make sure
> that
> > > we always use the same hashCode. I have created wrapper classes for the
> > map
> > > value as well but that was reverted to keep things consistent. Although
> > for
> > > the key I think we wouldn't break consistency. I updated the KIP.
> > >
> > > Thanks,
> > > Viktor
> > >
> > >
> > > On Tue, Apr 3, 2018 at 1:27 PM, Attila Sasvári 
> > > wrote:
> > >
> > > > Thanks for working on it Viktor.
> > > >
> > > > It looks good to me, but I have some questions:
> > > > - I see a new type DOUBLE is used for quota_value , and it is not
> > listed
> > > > among the primitive types on the Kafka protocol guide. Can you add
> some
> > > > more details?
> > > > - I am not sure that using an environment (i.e.
> > USE_OLD_COMMAND)variable
> > > is
> > > > the best way to control behaviour of kafka-config.sh . In other
> scripts
> > > > (e.g. console-consumer) an argument is passed (e.g. --new-consumer).
> If
> > > we
> > > > still want to use it, then I would suggest something like
> > > > USE_OLD_KAFKA_CONFIG_COMMAND. What do you think?
> > > > - I have seen maps like Map,
> > Collection>.
> > > > If List is the key type, you should make sure that
> this
> > > > List is immutable. Have you considered to introduce a new wrapper
> > class?
> > > >
> > > > Regards,
> > > > - Attila
> > > >
> > > > On Thu, Mar 29, 2018 at 1:46 PM, zhenya Sun  wrote:
> > > > >
> > > > >
> > > > >
> > > > > +1 （non-binding）
> > > > >
> > > > >
> > > > > | |
> > > > > zhenya Sun
> > > > > 邮箱：toke...@126.com
> > > > > |
> > > > >
> > > > > 签名由 网易邮箱大师 定制
> > > > >
> > > > > On 03/29/2018 19:40, Sandor Murakozi wrote:
> > > > > +1 (non-binding)
> > > > >
> > > > > Thanks for the KIP, Viktor
> > > > >
> > > > > On Wed, Mar 21, 2018 at 5:41 PM, Viktor Somogyi <
> > > viktorsomo...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Everyone,
> > > > > >
> > > > > > I've started a vote on KIP-248
> > > > > >  > > > 248+-+Create+New+
> > > > > > ConfigCommand+That+Uses+The+New+AdminClient#KIP-248-
> > > > > > CreateNewConfigCommandThatUsesTheNewAdminClient-DescribeQuotas>
> > > > > > a few weeks ago but at the time I got a couple more comments and
> it
> > > was
> > > > > > very close to 1.1 feature freeze, people were occupied with that,
> > so
> > > I
> > > > > > wanted to restart the vote on this.
> > > > > >
> > > > > >
> > > > > > *Summary of the KIP*
> > > > > > For those who don't have context I thought I'd summarize it in a
> > few
> > > > > > sentence.
> 

Re: [VOTE] #2 KIP-248: Create New ConfigCommand That Uses The New AdminClient

[zhenya Sun]

non-binding +1





from my iphone！
On 04/15/2018 15:41, Attila Sasvári wrote:
Thanks for updating the KIP.

+1 (non-binding)

Viktor Somogyi  ezt írta (időpont: 2018. ápr. 9.,
H 16:49):

> Hi Magnus,
>
> Thanks for the heads up, added the endianness to the KIP. Here is the
> current text:
>
> "Double
> A new type needs to be added to transfer quota values. Since the protocol
> classes in Kafka already uses ByteBuffers it is logical to use their
> functionality for serializing doubles. The serialization is basically a
> representation of the specified floating-point value according to the IEEE
> 754 floating-point "double format" bit layout. The ByteBuffer serializer
> writes eight bytes containing the given double value, in Big Endian byte
> order, into this buffer at the current position, and then increments the
> position by eight.
>
> The implementation will be defined in
> org.apache.kafka.common.protocol.types with the other protocol types and it
> will have no default value much like the other types available in the
> protocol."
>
> Also, I haven't changed the protocol docs yet but will do so in my PR for
> this feature.
>
> Let me know if you'd still add something.
>
> Regards,
> Viktor
>
>
> On Mon, Apr 9, 2018 at 3:32 PM, Magnus Edenhill 
> wrote:
>
> > Hi Viktor,
> >
> > since serialization of floats isn't as straight forward as integers,
> please
> > specify the exact serialization format of DOUBLE in the protocol docs
> > (e.g., IEEE 754),
> > including endianness (big-endian please).
> >
> > This will help the non-java client ecosystem.
> >
> > Thanks,
> > Magnus
> >
> >
> > 2018-04-09 15:16 GMT+02:00 Viktor Somogyi :
> >
> > > Hi Attila,
> > >
> > > 1. It uses ByteBuffers, which in turn will use Double.doubleToLongBits
> to
> > > convert the double value to a long and that long will be written in the
> > > buffer. I'v updated the KIP with this.
> > > 2. Good idea, modified it.
> > > 3. During the discussion I remember we didn't really decide which one
> > would
> > > be the better one but I agree that a wrapper class that makes sure the
> > list
> > > that is used as a key is immutable is a good idea and would ease the
> life
> > > of people using the interface. Also more importantly would make sure
> that
> > > we always use the same hashCode. I have created wrapper classes for the
> > map
> > > value as well but that was reverted to keep things consistent. Although
> > for
> > > the key I think we wouldn't break consistency. I updated the KIP.
> > >
> > > Thanks,
> > > Viktor
> > >
> > >
> > > On Tue, Apr 3, 2018 at 1:27 PM, Attila Sasvári 
> > > wrote:
> > >
> > > > Thanks for working on it Viktor.
> > > >
> > > > It looks good to me, but I have some questions:
> > > > - I see a new type DOUBLE is used for quota_value , and it is not
> > listed
> > > > among the primitive types on the Kafka protocol guide. Can you add
> some
> > > > more details?
> > > > - I am not sure that using an environment (i.e.
> > USE_OLD_COMMAND)variable
> > > is
> > > > the best way to control behaviour of kafka-config.sh . In other
> scripts
> > > > (e.g. console-consumer) an argument is passed (e.g. --new-consumer).
> If
> > > we
> > > > still want to use it, then I would suggest something like
> > > > USE_OLD_KAFKA_CONFIG_COMMAND. What do you think?
> > > > - I have seen maps like Map,
> > Collection>.
> > > > If List is the key type, you should make sure that
> this
> > > > List is immutable. Have you considered to introduce a new wrapper
> > class?
> > > >
> > > > Regards,
> > > > - Attila
> > > >
> > > > On Thu, Mar 29, 2018 at 1:46 PM, zhenya Sun  wrote:
> > > > >
> > > > >
> > > > >
> > > > > +1 （non-binding）
> > > > >
> > > > >
> > > > > | |
> > > > > zhenya Sun
> > > > > 邮箱：toke...@126.com
> > > > > |
> > > > >
> > > > > 签名由 网易邮箱大师 定制
> > > > >
> > > > > On 03/29/2018 19:40, Sandor Murakozi wrote:
> > > > > +1 (non-binding)
> > > > >
> > > > > Thanks for the KIP, Viktor
> > > > >
> > > > > On Wed, Mar 21, 2018 at 5:41 PM, Viktor Somogyi <
> > > viktorsomo...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Everyone,
> > > > > >
> > > > > > I've started a vote on KIP-248
> > > > > >  > > > 248+-+Create+New+
> > > > > > ConfigCommand+That+Uses+The+New+AdminClient#KIP-248-
> > > > > > CreateNewConfigCommandThatUsesTheNewAdminClient-DescribeQuotas>
> > > > > > a few weeks ago but at the time I got a couple more comments and
> it
> > > was
> > > > > > very close to 1.1 feature freeze, people were occupied with that,
> > so
> > > I
> > > > > > wanted to restart the vote on this.
> > > > > >
> > > > > >
> > > > > > *Summary of the KIP*
> > > > > > For those who don't have context I thought I'd summarize it in a
> > few
> > > > > > sentence.
> > > > > > *Problem & Motivation: *The basic problem that the KIP tries to
> > solve
> > > > is
> > > > > > that kafka-configs.sh (which in turn uses the ConfigCommand
> class)
> > > uses
> > > > a
> > 

Re: [VOTE] #2 KIP-248: Create New ConfigCommand That Uses The New AdminClient

[Attila Sasvári]

Thanks for updating the KIP.

+1 (non-binding)

Viktor Somogyi  ezt írta (időpont: 2018. ápr. 9.,
H 16:49):

> Hi Magnus,
>
> Thanks for the heads up, added the endianness to the KIP. Here is the
> current text:
>
> "Double
> A new type needs to be added to transfer quota values. Since the protocol
> classes in Kafka already uses ByteBuffers it is logical to use their
> functionality for serializing doubles. The serialization is basically a
> representation of the specified floating-point value according to the IEEE
> 754 floating-point "double format" bit layout. The ByteBuffer serializer
> writes eight bytes containing the given double value, in Big Endian byte
> order, into this buffer at the current position, and then increments the
> position by eight.
>
> The implementation will be defined in
> org.apache.kafka.common.protocol.types with the other protocol types and it
> will have no default value much like the other types available in the
> protocol."
>
> Also, I haven't changed the protocol docs yet but will do so in my PR for
> this feature.
>
> Let me know if you'd still add something.
>
> Regards,
> Viktor
>
>
> On Mon, Apr 9, 2018 at 3:32 PM, Magnus Edenhill 
> wrote:
>
> > Hi Viktor,
> >
> > since serialization of floats isn't as straight forward as integers,
> please
> > specify the exact serialization format of DOUBLE in the protocol docs
> > (e.g., IEEE 754),
> > including endianness (big-endian please).
> >
> > This will help the non-java client ecosystem.
> >
> > Thanks,
> > Magnus
> >
> >
> > 2018-04-09 15:16 GMT+02:00 Viktor Somogyi :
> >
> > > Hi Attila,
> > >
> > > 1. It uses ByteBuffers, which in turn will use Double.doubleToLongBits
> to
> > > convert the double value to a long and that long will be written in the
> > > buffer. I'v updated the KIP with this.
> > > 2. Good idea, modified it.
> > > 3. During the discussion I remember we didn't really decide which one
> > would
> > > be the better one but I agree that a wrapper class that makes sure the
> > list
> > > that is used as a key is immutable is a good idea and would ease the
> life
> > > of people using the interface. Also more importantly would make sure
> that
> > > we always use the same hashCode. I have created wrapper classes for the
> > map
> > > value as well but that was reverted to keep things consistent. Although
> > for
> > > the key I think we wouldn't break consistency. I updated the KIP.
> > >
> > > Thanks,
> > > Viktor
> > >
> > >
> > > On Tue, Apr 3, 2018 at 1:27 PM, Attila Sasvári 
> > > wrote:
> > >
> > > > Thanks for working on it Viktor.
> > > >
> > > > It looks good to me, but I have some questions:
> > > > - I see a new type DOUBLE is used for quota_value , and it is not
> > listed
> > > > among the primitive types on the Kafka protocol guide. Can you add
> some
> > > > more details?
> > > > - I am not sure that using an environment (i.e.
> > USE_OLD_COMMAND)variable
> > > is
> > > > the best way to control behaviour of kafka-config.sh . In other
> scripts
> > > > (e.g. console-consumer) an argument is passed (e.g. --new-consumer).
> If
> > > we
> > > > still want to use it, then I would suggest something like
> > > > USE_OLD_KAFKA_CONFIG_COMMAND. What do you think?
> > > > - I have seen maps like Map,
> > Collection>.
> > > > If List is the key type, you should make sure that
> this
> > > > List is immutable. Have you considered to introduce a new wrapper
> > class?
> > > >
> > > > Regards,
> > > > - Attila
> > > >
> > > > On Thu, Mar 29, 2018 at 1:46 PM, zhenya Sun  wrote:
> > > > >
> > > > >
> > > > >
> > > > > +1 （non-binding）
> > > > >
> > > > >
> > > > > | |
> > > > > zhenya Sun
> > > > > 邮箱：toke...@126.com
> > > > > |
> > > > >
> > > > > 签名由 网易邮箱大师 定制
> > > > >
> > > > > On 03/29/2018 19:40, Sandor Murakozi wrote:
> > > > > +1 (non-binding)
> > > > >
> > > > > Thanks for the KIP, Viktor
> > > > >
> > > > > On Wed, Mar 21, 2018 at 5:41 PM, Viktor Somogyi <
> > > viktorsomo...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Everyone,
> > > > > >
> > > > > > I've started a vote on KIP-248
> > > > > >  > > > 248+-+Create+New+
> > > > > > ConfigCommand+That+Uses+The+New+AdminClient#KIP-248-
> > > > > > CreateNewConfigCommandThatUsesTheNewAdminClient-DescribeQuotas>
> > > > > > a few weeks ago but at the time I got a couple more comments and
> it
> > > was
> > > > > > very close to 1.1 feature freeze, people were occupied with that,
> > so
> > > I
> > > > > > wanted to restart the vote on this.
> > > > > >
> > > > > >
> > > > > > *Summary of the KIP*
> > > > > > For those who don't have context I thought I'd summarize it in a
> > few
> > > > > > sentence.
> > > > > > *Problem & Motivation: *The basic problem that the KIP tries to
> > solve
> > > > is
> > > > > > that kafka-configs.sh (which in turn uses the ConfigCommand
> class)
> > > uses
> > > > a
> > > > > > direct zookeeper connection. This is not desirable as getting
> > aroun