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

Thanks Guozhang, LGTM On Fri, 2 Mar 2018 at 03:00 Hu Xi wrote: > Guozhang, > > > Thanks for this KIP. Please help confirm questions below: > > 1. Do we also need to retrofit `SimpleConsumerShell` to have it > support these newly-added serdes? > 2. Does this KIP cover the changes for Cons

Re: [kafka-clients] Re: [VOTE] 1.1.0 RC0

Thanks Jun On Fri, 2 Mar 2018 at 02:25 Jun Rao wrote: > KAFKA-6111 is now merged to 1.1 branch. > > Thanks, > > Jun > > On Thu, Mar 1, 2018 at 2:50 PM, Jun Rao wrote: > >> Hi, Damian, >> >> It would also be useful to include KAFKA-6111, which prevents >> deleteLogDirEventNotifications >> path

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

@Xi: 1. SimpleConsumerShell is marked as deprecated in 0.11.0 and will be removed soon in the future releases, so I did not consider it in this KIP. 2. Yes, it is contained in the Public Interfaces section of the wiki, please read the section and let me know (it is slightly different with your pro

Re: [VOTE] 1.0.1 RC2

Thanks everyone for voting. This passes with 3 binding +1, 5 non-binding +1, and no dissenting votes. I'll work on getting the release finalized and send out an announcement when it is ready. -Ewen On Tue, Feb 27, 2018 at 11:18 PM, Jason Gustafson wrote: > +1. Verified artifacts and ran the ba

Re: [VOTE] 1.0.1 RC2

Thanks for running the release Ewen! Ismael On Fri, Mar 2, 2018 at 10:10 AM, Ewen Cheslack-Postava wrote: > Thanks everyone for voting. This passes with 3 binding +1, 5 non-binding > +1, and no dissenting votes. > > I'll work on getting the release finalized and send out an announcement > when

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

See -- [...truncated 416.36 KB...] kafka.server.epoch.LeaderEpochFileCacheTest > shouldReturnUnsupportedIfNoEpochRecorded PASSED kafka.server.epoch.LeaderEpochFileCacheTest > shouldRet

Re: [DISCUSS] KIP-253: Support in-order message delivery with partition expansion

Hey Dong, Cool, obviously we'd need to have a solution here work with connect and streams to be viable. On the linear hashing thing, what I am talking about is something different. I am talking about splitting existing partitions incrementally. E.g. if you have 100 partitions and want to move to

[jira] [Created] (KAFKA-6606) Regression in consumer auto-commit backoff behavior

Jason Gustafson created KAFKA-6606: -- Summary: Regression in consumer auto-commit backoff behavior Key: KAFKA-6606 URL: https://issues.apache.org/jira/browse/KAFKA-6606 Project: Kafka Issue T

Jenkins build is back to normal : kafka-0.11.0-jdk7 #361

See

Re: [DISCUSS] KIP-211: Revise Expiration Semantics of Consumer Group Offsets

Hi Jason, I'm thinking through some of the details of the KIP with respect to your feedback and the decision to keep the expire-timestamp for each group partition in the offset message. On point #1 below: since the expiration timer starts ticking after the group becomes Empty the expire_timest

[jira] [Created] (KAFKA-6607) Kafka Streams lag not zero when input topic transactional

Matthias J. Sax created KAFKA-6607: -- Summary: Kafka Streams lag not zero when input topic transactional Key: KAFKA-6607 URL: https://issues.apache.org/jira/browse/KAFKA-6607 Project: Kafka I

Build failed in Jenkins: kafka-trunk-jdk9 #444

See -- [...truncated 1.24 MB...] kafka.security.auth.ResourceTypeTest > testJavaConversions PASSED kafka.security.auth.ResourceTypeTest > testFromString STARTED kafka.security.auth.Reso

Re: [DISCUSS] KIP-253: Support in-order message delivery with partition expansion

linear hashing (or partition splitting) vs rehashing every key: The benefit of the former is that it reduces the # of partitions to which keys from an existing partition are re-distributed, which potentially reduces the overhead of rebuilding the state in a consumer. The downside is that the load m

Re: [DISCUSS] KIP-263: Allow broker to skip sanity check of inactive segments on broker startup

Hi Dong, This seems like a nice improvement. Is there any way we could avoid adding a new configuration value? It's not clear to me why we would want the old behavior. best, Colin On Tue, Feb 27, 2018, at 23:57, Stephane Maarek wrote: > This is great and definitely needed. I'm not exactly su

[jira] [Resolved] (KAFKA-4854) Producer RecordBatch executes callbacks with `null` provided for metadata if an exception is encountered

[ https://issues.apache.org/jira/browse/KAFKA-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ewen Cheslack-Postava resolved KAFKA-4854. -- Resolution: Not A Bug Assignee: Ewen Cheslack-Postava This behavior is int