[jira] [Created] (KAFKA-9822) java kafka-client use "props.put("acks", "1")" ,but print 2 log , but 3 log better..

startjava created KAFKA-9822: Summary: java kafka-client use "props.put("acks", "1")" ,but print 2 log , but 3 log better.. Key: KAFKA-9822 URL: https://issues.apache.org/jira/browse/KAFKA-9822 Project: K

Re: [DISCUSS] KIP-584: Versioning scheme for features

On Fri, Apr 3, 2020, at 11:24, Jun Rao wrote: > Hi, Kowshik, > > Thanks for the reply. A few more comments below. > > 100.6 For every new request, the admin needs to control who is allowed > to issue that request if security is enabled. So, we need to assign the new > request a ResourceType and

Re: [DISCUSS] KIP-584: Versioning scheme for features

On Fri, Apr 3, 2020, at 20:32, Kowshik Prakasam wrote: > > Colin wrote: > > It would be simpler to just say that a feature flag which doesn't appear > > in the znode is considered to be at version level 0. This will also > > simplify the code a lot, I think, since you won't have to keep track of >

[jira] [Resolved] (KAFKA-9810) Document Connect Root REST API on /

[ https://issues.apache.org/jira/browse/KAFKA-9810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantine Karantasis resolved KAFKA-9810. --- Resolution: Fixed > Document Connect Root REST API on / > -

Jenkins build is back to normal : kafka-trunk-jdk11 #1324

See

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

See

Re: 2.5.0 Producer.sendOffsetsToTransaction() and Backwards Compatibility

That’s a fair point Ismael. After a second thought, I feel that if Gary is building frameworks for general purpose usage, relying on private flag seems not a good idea. On Sat, Apr 4, 2020 at 10:01 AM Ismael Juma wrote: > The internal config was meant to be internal, right? That is, no > compati

Build failed in Jenkins: kafka-2.2-jdk8 #43

See Changes: [bill] KAFKA-9739: 2.3 null child node fix (#8419) -- [...truncated 2.59 MB...] kafka.utils.CommandLineUtilsTest > testParseArgs STARTED kafka.utils.CommandLin

Build failed in Jenkins: kafka-trunk-jdk11 #1323

See Changes: [github] KAFKA-9820: validateMessagesAndAssignOffsetsCompressed allocates unused [github] MINOR: Remove redundant braces from log message in FetchSessionHandler --

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

See Changes: [github] KAFKA-9820: validateMessagesAndAssignOffsetsCompressed allocates unused -- [...truncated 2.06 MB...] org.apache.kafka.connect.transforms.CastTest >

[jira] [Resolved] (KAFKA-9820) validateMessagesAndAssignOffsetsCompressed allocates batch iterator which is not used

[ https://issues.apache.org/jira/browse/KAFKA-9820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma resolved KAFKA-9820. Resolution: Fixed > validateMessagesAndAssignOffsetsCompressed allocates batch iterator which is >

Re: 2.5.0 Producer.sendOffsetsToTransaction() and Backwards Compatibility

The internal config was meant to be internal, right? That is, no compatibility guarantees are offered? The current discussion implies we are considering it a public config. Ismael On Sat, Apr 4, 2020 at 9:31 AM Boyang Chen wrote: > For Gary's case, I think the internal config should be a sort o

Re: 2.5.0 Producer.sendOffsetsToTransaction() and Backwards Compatibility

For Gary's case, I think the internal config should be a sort of help, and not violating our public agreement. On Fri, Apr 3, 2020 at 7:44 PM Matthias J. Sax wrote: > I guess you would need to catch the exception and retry? > > It's a little unfortunate. Not sure if we could back-port the intern

Build failed in Jenkins: kafka-2.4-jdk8 #183

See Changes: [konstantine] KAFKA-9810: Document Connect Root REST API on / (#8408) [jason] KAFKA-9807; Protect LSO reads from concurrent high-watermark updates -- [...trunc

Re: [VOTE] KIP-221: Enhance KStream with Connecting Topic Creation and Repartition Hint

Hello, Small update regarding this KIP. As per John’s suggestion during the code review (https://github.com/apache/kafka/pull/7170#discussion_r392608571 ) we’ve decided to remove KeyValueMapper overloads for the new `repartition`