Re: [DISCUSS] KIP-111 : Kafka should preserve the Principal generated by the PrincipalBuilder while processing the request received on socket channel, on the broker.

2017-01-28 Thread Mayuresh Gharat
I had offline discussions with Joel, Dong and Radai. I agree that we can replace the KafkaPrincipal in Session with the ChannelPrincipal. KafkaPrincipal can be provided as an out of box implementation. The only gotcha will be users will have to implement there own Authorizer, if they decide to us

Re: [VOTE] KIP-115: Enforce offsets.topic.replication.factor

2017-01-28 Thread Onur Karaman
Closing the vote. KIP-115 has been accepted by: 4 binding +1s: Ismael, Jason, Joel, Ewen 6 nonbindng +1s: Dong, James, Ben, Mickael, Rajini, Colin Thanks, everyone! On Thu, Jan 26, 2017 at 9:34 AM, Colin McCabe wrote: > +1 (non-binding) > > > > On Wed, Jan 25, 2017, at 16:34, Onur Karaman wrote

[jira] [Commented] (KAFKA-4689) OffsetValidationTest fails validation with "Current position greater than the total number of consumed records"

2017-01-28 Thread Ewen Cheslack-Postava (JIRA)
[ https://issues.apache.org/jira/browse/KAFKA-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15844221#comment-15844221 ] Ewen Cheslack-Postava commented on KAFKA-4689: -- Actually, the error message i

[jira] [Commented] (KAFKA-4689) OffsetValidationTest fails validation with "Current position greater than the total number of consumed records"

2017-01-28 Thread Ewen Cheslack-Postava (JIRA)
[ https://issues.apache.org/jira/browse/KAFKA-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15844219#comment-15844219 ] Ewen Cheslack-Postava commented on KAFKA-4689: -- [~hachikuji] Any further thou

[jira] [Created] (KAFKA-4709) Error message from Struct.validate() should include the name of the offending field.

2017-01-28 Thread Jeremy Custenborder (JIRA)
Jeremy Custenborder created KAFKA-4709: -- Summary: Error message from Struct.validate() should include the name of the offending field. Key: KAFKA-4709 URL: https://issues.apache.org/jira/browse/KAFKA-4709

[jira] [Commented] (KAFKA-4706) Unify StreamsKafkaClient instances

2017-01-28 Thread Roy Majumdar (JIRA)
[ https://issues.apache.org/jira/browse/KAFKA-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15844142#comment-15844142 ] Roy Majumdar commented on KAFKA-4706: - Hi as a newcomer to Kafka and a beginner how sh

Re: [DISCUSS] KIP-114: KTable materialization and improved semantics

2017-01-28 Thread Damian Guy
Retrieving the Queryable Store from the KTable is a possibility, i.e., you could have something like: QueryableStore store = ktable.queryableStore(); Where QueryableStore (i'm making these names up and not suggesting we use them) is just a proxy to the underlying stores. This would be useful for

Re: [DISCUSS] KIP-114: KTable materialization and improved semantics

2017-01-28 Thread Eno Thereska
Hi Gwen, Jan, So in addition to behaving as a hint, providing a state store name (in materialize or overloaded) allows the user to subsequently query by using that name. KTables have internal names, largely opaque to the users. When doing distributed queries with IQ, a state store name is neede

Re: [DISCUSS] KIP-114: KTable materialization and improved semantics

2017-01-28 Thread Eno Thereska
Hi Jan, I understand your concern. One implication of not passing any store name and just getting an IQ handle is that all KTables would need to be materialised. Currently the store name (or proposed .materialize() call) act as hints on whether to materialise the KTable or not. Materialising ev