[jira] [Resolved] (KAFKA-13535) Workaround for mitigating CVE-2021-44228 Kafka
[ https://issues.apache.org/jira/browse/KAFKA-13535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luke Chen resolved KAFKA-13535. --- Resolution: Won't Fix [~akansh] , thanks for reporting the issue. I've confirmed that Kafka is not affected by this CVE. Please read my email reply here for more detail: [https://lists.apache.org/thread/lgbtvvmy68p0059yoyn9qxzosdmx4jdv] Thank you. > Workaround for mitigating CVE-2021-44228 Kafka > --- > > Key: KAFKA-13535 > URL: https://issues.apache.org/jira/browse/KAFKA-13535 > Project: Kafka > Issue Type: Bug >Affects Versions: 2.8.1 >Reporter: Akansh Shandilya >Priority: Major > > Kafka v2.8.1 uses log4j v1.x . Please review following information : > > Is Kafka v2.8.1 impacted by CVE-2021-44228? > If yes, is there any workaround/recommendation available for Kafka v2.8.1 to > mitigate CVE-2021-44228 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KAFKA-13534) Upgrade Log4j to 2.15.0 - CVE-2021-44228
[ https://issues.apache.org/jira/browse/KAFKA-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457566#comment-17457566 ] Luke Chen commented on KAFKA-13534: --- [~svudutala] , thanks for reporting the issue. I've confirmed that Kafka is not affected by this CVE. Please read my email reply here for more detail: [https://lists.apache.org/thread/lgbtvvmy68p0059yoyn9qxzosdmx4jdv] But we have a KIP to upgrade log4j to log4j2. I'll link this ticket to that: KAFKA-9366 Thank you. > Upgrade Log4j to 2.15.0 - CVE-2021-44228 > > > Key: KAFKA-13534 > URL: https://issues.apache.org/jira/browse/KAFKA-13534 > Project: Kafka > Issue Type: Task >Affects Versions: 2.7.0, 2.8.0, 3.0.0 >Reporter: Sai Kiran Vudutala >Priority: Major > > Log4j has an RCE vulnerability, see > [https://www.lunasec.io/docs/blog/log4j-zero-day/] > References. > [https://github.com/advisories/GHSA-jfh8-c2jp-5v3q] > [https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KAFKA-13534) Upgrade Log4j to 2.15.0 - CVE-2021-44228
[ https://issues.apache.org/jira/browse/KAFKA-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457568#comment-17457568 ] Jason-Morries Adam commented on KAFKA-13534: [~showuon] In my opinion, Log4J v1 is vulnerable for other issues, so an upgrade would be great: [https://github.com/apache/logging-log4j2/pull/608?s=09#issuecomment-990494126] > Upgrade Log4j to 2.15.0 - CVE-2021-44228 > > > Key: KAFKA-13534 > URL: https://issues.apache.org/jira/browse/KAFKA-13534 > Project: Kafka > Issue Type: Task >Affects Versions: 2.7.0, 2.8.0, 3.0.0 >Reporter: Sai Kiran Vudutala >Priority: Major > > Log4j has an RCE vulnerability, see > [https://www.lunasec.io/docs/blog/log4j-zero-day/] > References. > [https://github.com/advisories/GHSA-jfh8-c2jp-5v3q] > [https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [kafka] ayu-programer opened a new pull request #11594: How to define the quantity of consumption groups
ayu-programer opened a new pull request #11594: URL: https://github.com/apache/kafka/pull/11594 Now I have more than 30 topics to consume, and each topic has 6 partitions. I need to write files through the consumer program. I don't know how many consumer groups to create? I understand that a consumer group can consume multiple topics, but is it appropriate in this scenario? Can you give me some advice? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] dajac commented on pull request #11571: KAFKA-13496: add reason to LeaveGroupRequest
dajac commented on pull request #11571: URL: https://github.com/apache/kafka/pull/11571#issuecomment-991664350 @jeffkbkim That's right. We have to bump the version of both the request and the response. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] priyavj08 commented on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
priyavj08 commented on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991672999 > Agree. After reconsidering the issue, I concluded that [CVE-2019-17571](https://github.com/advisories/GHSA-2qrg-x229-3v8q) is rather a minor issue; It is only problematic only when the user tries to use the `SocketServer` appender. hi @dongjinleekr, do we know if kafka 2.8.1 exposed to this vulnerability CVE-2021-44228? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] priyavj08 removed a comment on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
priyavj08 removed a comment on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991672999 > Agree. After reconsidering the issue, I concluded that [CVE-2019-17571](https://github.com/advisories/GHSA-2qrg-x229-3v8q) is rather a minor issue; It is only problematic only when the user tries to use the `SocketServer` appender. hi @dongjinleekr, do we know if kafka 2.8.1 exposed to this vulnerability CVE-2021-44228? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] jetlyg commented on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
jetlyg commented on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991704123 > > Will this PR solve [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)? > > @soumiksamanta > > https://github.com/apache/kafka/blob/bd3038383265f7bb850c09fe0a74a48c5c2e6f99/gradle/dependencies.gradle#L78 > > should be upgraded to 2.15.0. log4j <= 2.14.0 all have this issue. > Initially I thought log4j 1.x is not impacted but as per [apache/logging-log4j2#608 (comment)](https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126) it is. but kafka does not use JMS appender. Will it still be impacted? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] jetlyg removed a comment on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
jetlyg removed a comment on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991704123 > > Will this PR solve [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)? > > @soumiksamanta > > https://github.com/apache/kafka/blob/bd3038383265f7bb850c09fe0a74a48c5c2e6f99/gradle/dependencies.gradle#L78 > > should be upgraded to 2.15.0. log4j <= 2.14.0 all have this issue. > Initially I thought log4j 1.x is not impacted but as per [apache/logging-log4j2#608 (comment)](https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126) it is. but kafka does not use JMS appender. Will it still be impacted? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] jetlyg commented on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
jetlyg commented on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991704864 > > Will this PR solve [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)? > > @soumiksamanta > > https://github.com/apache/kafka/blob/bd3038383265f7bb850c09fe0a74a48c5c2e6f99/gradle/dependencies.gradle#L78 > > should be upgraded to 2.15.0. log4j <= 2.14.0 all have this issue. > Initially I thought log4j 1.x is not impacted but as per [apache/logging-log4j2#608 (comment)](https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126) it is. But kafka by default does not use JMS appender. Will it still be impacted. The comment you referenced above talks about log4j in general. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] jetlyg removed a comment on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
jetlyg removed a comment on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991704864 > > Will this PR solve [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)? > > @soumiksamanta > > https://github.com/apache/kafka/blob/bd3038383265f7bb850c09fe0a74a48c5c2e6f99/gradle/dependencies.gradle#L78 > > should be upgraded to 2.15.0. log4j <= 2.14.0 all have this issue. > Initially I thought log4j 1.x is not impacted but as per [apache/logging-log4j2#608 (comment)](https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126) it is. But kafka by default does not use JMS appender. Will it still be impacted. The comment you referenced above talks about log4j in general. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] unverified-user commented on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
unverified-user commented on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991705948 > > Will this PR solve [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)? > > @soumiksamanta > > https://github.com/apache/kafka/blob/bd3038383265f7bb850c09fe0a74a48c5c2e6f99/gradle/dependencies.gradle#L78 > > should be upgraded to 2.15.0. log4j <= 2.14.0 all have this issue. > Initially I thought log4j 1.x is not impacted but as per [apache/logging-log4j2#608 (comment)](https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126) it is. Thank you for sharing the comment. Isn't that comment for log4j v1 in general. kafka by default does not use JMS appender. Do you think it is impacted under the default configuration. Also refer to this post: https://lists.apache.org/thread/lgbtvvmy68p0059yoyn9qxzosdmx4jdv -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (KAFKA-13535) Workaround for mitigating CVE-2021-44228 Kafka
[ https://issues.apache.org/jira/browse/KAFKA-13535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457701#comment-17457701 ] vijay commented on KAFKA-13535: --- Hi Luke I am using kafka 2.0 and and log4j is 1.2.17 . and i dont see log4j-core* jar . ./kafka-topics.sh --version 2.0.0 ./libs/log4j-1.2.17.jar is this version got affected by this . > Workaround for mitigating CVE-2021-44228 Kafka > --- > > Key: KAFKA-13535 > URL: https://issues.apache.org/jira/browse/KAFKA-13535 > Project: Kafka > Issue Type: Bug >Affects Versions: 2.8.1 >Reporter: Akansh Shandilya >Priority: Major > > Kafka v2.8.1 uses log4j v1.x . Please review following information : > > Is Kafka v2.8.1 impacted by CVE-2021-44228? > If yes, is there any workaround/recommendation available for Kafka v2.8.1 to > mitigate CVE-2021-44228 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [kafka] lbradstreet opened a new pull request #11595: MINOR: timeout waitForBlock in connect BlockingConnectorTest
lbradstreet opened a new pull request #11595: URL: https://github.com/apache/kafka/pull/11595 I've noticed some builds timing out on BlockingConnectorTest. This adds a timeout around the latch usage. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (KAFKA-13530) Flaky test ReplicaManagerTest
[
https://issues.apache.org/jira/browse/KAFKA-13530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457714#comment-17457714
]
Lucas Bradstreet commented on KAFKA-13530:
--
Just to note, the error checkpointing appears to be a different test.
> Flaky test ReplicaManagerTest
> -
>
> Key: KAFKA-13530
> URL: https://issues.apache.org/jira/browse/KAFKA-13530
> Project: Kafka
> Issue Type: Test
> Components: core, unit tests
>Reporter: Matthias J. Sax
>Priority: Critical
> Labels: flaky-test
>
> kafka.server.ReplicaManagerTest.[1] usesTopicIds=true
> {quote}org.opentest4j.AssertionFailedError: expected: but was:
> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at
> org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at
> org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:35) at
> org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:162) at
> kafka.server.ReplicaManagerTest.assertFetcherHasTopicId(ReplicaManagerTest.scala:3502)
> at
> kafka.server.ReplicaManagerTest.testReplicaAlterLogDirsWithAndWithoutIds(ReplicaManagerTest.scala:3572){quote}
> STDOUT
> {quote}[2021-12-07 16:19:35,906] ERROR Error while reading checkpoint file
> /tmp/kafka-6310287969113820536/replication-offset-checkpoint
> (kafka.server.LogDirFailureChannel:76) java.nio.file.NoSuchFileException:
> /tmp/kafka-6310287969113820536/replication-offset-checkpoint at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at
> sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel(Files.java:361) at
> java.nio.file.Files.newByteChannel(Files.java:407) at
> java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream(Files.java:152) at
> java.nio.file.Files.newBufferedReader(Files.java:2784) at
> java.nio.file.Files.newBufferedReader(Files.java:2816) at
> org.apache.kafka.server.common.CheckpointFile.read(CheckpointFile.java:104)
> at
> kafka.server.checkpoints.CheckpointFileWithFailureHandler.read(CheckpointFileWithFailureHandler.scala:48)
> at
> kafka.server.checkpoints.OffsetCheckpointFile.read(OffsetCheckpointFile.scala:70)
> at
> kafka.server.checkpoints.LazyOffsetCheckpointMap.offsets$lzycompute(OffsetCheckpointFile.scala:94)
> at
> kafka.server.checkpoints.LazyOffsetCheckpointMap.offsets(OffsetCheckpointFile.scala:94)
> at
> kafka.server.checkpoints.LazyOffsetCheckpointMap.fetch(OffsetCheckpointFile.scala:97)
> at
> kafka.server.checkpoints.LazyOffsetCheckpoints.fetch(OffsetCheckpointFile.scala:89)
> at kafka.cluster.Partition.updateHighWatermark$1(Partition.scala:348) at
> kafka.cluster.Partition.createLog(Partition.scala:361) at
> kafka.cluster.Partition.maybeCreate$1(Partition.scala:334) at
> kafka.cluster.Partition.createLogIfNotExists(Partition.scala:341) at
> kafka.cluster.Partition.$anonfun$makeLeader$1(Partition.scala:546) at
> kafka.cluster.Partition.makeLeader(Partition.scala:530) at
> kafka.server.ReplicaManager.$anonfun$applyLocalLeadersDelta$3(ReplicaManager.scala:2163)
> at scala.Option.foreach(Option.scala:437) at
> kafka.server.ReplicaManager.$anonfun$applyLocalLeadersDelta$2(ReplicaManager.scala:2160)
> at
> kafka.server.ReplicaManager.$anonfun$applyLocalLeadersDelta$2$adapted(ReplicaManager.scala:2159)
> at
> kafka.utils.Implicits$MapExtensionMethods$.$anonfun$forKeyValue$1(Implicits.scala:62)
> at
> scala.collection.convert.JavaCollectionWrappers$JMapWrapperLike.foreachEntry(JavaCollectionWrappers.scala:359)
> at
> scala.collection.convert.JavaCollectionWrappers$JMapWrapperLike.foreachEntry$(JavaCollectionWrappers.scala:355)
> at
> scala.collection.convert.JavaCollectionWrappers$AbstractJMapWrapper.foreachEntry(JavaCollectionWrappers.scala:309)
> at
> kafka.server.ReplicaManager.applyLocalLeadersDelta(ReplicaManager.scala:2159)
> at kafka.server.ReplicaManager.applyDelta(ReplicaManager.scala:2136) at
> kafka.server.ReplicaManagerTest.testDeltaToLeaderOrFollowerMarksPartitionOfflineIfLogCantBeCreated(ReplicaManagerTest.scala:3349){quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (KAFKA-13530) Flaky test ReplicaManagerTest
[
https://issues.apache.org/jira/browse/KAFKA-13530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457716#comment-17457716
]
Lucas Bradstreet commented on KAFKA-13530:
--
[~jolshan] if you look at some of the other tests, they use a CountDownLatch
with their mock to control the timing of how things complete, e.g. this setup:
{noformat}
val countDownLatch = new CountDownLatch(1)
// Prepare the mocked components for the test
val (replicaManager, mockLogMgr) = prepareReplicaManagerAndLogManager(new
MockTimer(time),
topicPartition, leaderEpoch + leaderEpochIncrement, followerBrokerId,
leaderBrokerId, countDownLatch,
expectTruncation = expectTruncation, localLogOffset = Some(10), extraProps =
extraProps, topicId = Some(topicId)){noformat}
That allows you do things like ensure that the fetcher thread blocks in a
certain state where you can validate the state:
{code:java}
override def createFetcherThread(fetcherId: Int, sourceBroker: BrokerEndPoint):
ReplicaFetcherThread = {
new ReplicaFetcherThread(s"ReplicaFetcherThread-$fetcherId", fetcherId,
sourceBroker, config, failedPartitions, replicaManager, metrics, time,
quotaManager.follower, Some(blockingSend)) {
override def doWork() = {
// In case the thread starts before the partition is added by
AbstractFetcherManager,
// add it here (it's a no-op if already added)
val initialOffset = InitialFetchState(
topicId = topicId,
leader = new BrokerEndPoint(0, "localhost", 9092),
initOffset = 0L, currentLeaderEpoch = leaderEpochInLeaderAndIsr)
addPartitions(Map(new TopicPartition(topic, topicPartition) ->
initialOffset))
super.doWork()
// Shut the thread down after one iteration to avoid double-counting
truncations
initiateShutdown()
countDownLatch.countDown()
}
}
}
{code}
Maybe something like that would be helpful?
> Flaky test ReplicaManagerTest
> -
>
> Key: KAFKA-13530
> URL: https://issues.apache.org/jira/browse/KAFKA-13530
> Project: Kafka
> Issue Type: Test
> Components: core, unit tests
>Reporter: Matthias J. Sax
>Priority: Critical
> Labels: flaky-test
>
> kafka.server.ReplicaManagerTest.[1] usesTopicIds=true
> {quote}org.opentest4j.AssertionFailedError: expected: but was:
> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at
> org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at
> org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:35) at
> org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:162) at
> kafka.server.ReplicaManagerTest.assertFetcherHasTopicId(ReplicaManagerTest.scala:3502)
> at
> kafka.server.ReplicaManagerTest.testReplicaAlterLogDirsWithAndWithoutIds(ReplicaManagerTest.scala:3572){quote}
> STDOUT
> {quote}[2021-12-07 16:19:35,906] ERROR Error while reading checkpoint file
> /tmp/kafka-6310287969113820536/replication-offset-checkpoint
> (kafka.server.LogDirFailureChannel:76) java.nio.file.NoSuchFileException:
> /tmp/kafka-6310287969113820536/replication-offset-checkpoint at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at
> sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel(Files.java:361) at
> java.nio.file.Files.newByteChannel(Files.java:407) at
> java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream(Files.java:152) at
> java.nio.file.Files.newBufferedReader(Files.java:2784) at
> java.nio.file.Files.newBufferedReader(Files.java:2816) at
> org.apache.kafka.server.common.CheckpointFile.read(CheckpointFile.java:104)
> at
> kafka.server.checkpoints.CheckpointFileWithFailureHandler.read(CheckpointFileWithFailureHandler.scala:48)
> at
> kafka.server.checkpoints.OffsetCheckpointFile.read(OffsetCheckpointFile.scala:70)
> at
> kafka.server.checkpoints.LazyOffsetCheckpointMap.offsets$lzycompute(OffsetCheckpointFile.scala:94)
> at
> kafka.server.checkpoints.LazyOffsetCheckpointMap.offsets(OffsetCheckpointFile.scala:94)
> at
> kafka.server.checkpoints.LazyOffsetCheckpointMap.fetch(OffsetCheckpointFile.scala:97)
> at
> kafka.server.checkpoints.LazyOffsetCheckpoints.fetch(OffsetCheckpointFile.scala:89)
> at kafka.cluster.Partition.updateHighWatermark$1(Partition.scala:348) at
> kafka.cluster.Partition.createLog(Partition.scala:361) at
> kafka.cluster.Partition.maybeCreate$1(Partition.scala:334) at
> kafka.cluster.Partition.createLogIfNotExists(Partition.scala:341) at
> kafka.cluster.Partition.$anonfun$makeLeader$1(Partition.scala:546) at
> kaf
[jira] [Comment Edited] (KAFKA-13534) Upgrade Log4j to 2.15.0 - CVE-2021-44228
[ https://issues.apache.org/jira/browse/KAFKA-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457568#comment-17457568 ] Jason-Morries Adam edited comment on KAFKA-13534 at 12/12/21, 12:30 AM: [~showuon] In my opinion, Log4J v1 is vulnerable for other issues, so an upgrade would be the only acceptable option: [https://github.com/apache/logging-log4j2/pull/608?s=09#issuecomment-990494126] was (Author: jasonmadam): [~showuon] In my opinion, Log4J v1 is vulnerable for other issues, so an upgrade would be great: [https://github.com/apache/logging-log4j2/pull/608?s=09#issuecomment-990494126] > Upgrade Log4j to 2.15.0 - CVE-2021-44228 > > > Key: KAFKA-13534 > URL: https://issues.apache.org/jira/browse/KAFKA-13534 > Project: Kafka > Issue Type: Task >Affects Versions: 2.7.0, 2.8.0, 3.0.0 >Reporter: Sai Kiran Vudutala >Priority: Major > > Log4j has an RCE vulnerability, see > [https://www.lunasec.io/docs/blog/log4j-zero-day/] > References. > [https://github.com/advisories/GHSA-jfh8-c2jp-5v3q] > [https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KAFKA-13535) Workaround for mitigating CVE-2021-44228 Kafka
[ https://issues.apache.org/jira/browse/KAFKA-13535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457798#comment-17457798 ] Luke Chen commented on KAFKA-13535: --- No, log4j-1.x.x versions are not affected by this CVE (based on the author of log4j 1 project, and one of the log4j 2 PMC member). Thanks. > Workaround for mitigating CVE-2021-44228 Kafka > --- > > Key: KAFKA-13535 > URL: https://issues.apache.org/jira/browse/KAFKA-13535 > Project: Kafka > Issue Type: Bug >Affects Versions: 2.8.1 >Reporter: Akansh Shandilya >Priority: Major > > Kafka v2.8.1 uses log4j v1.x . Please review following information : > > Is Kafka v2.8.1 impacted by CVE-2021-44228? > If yes, is there any workaround/recommendation available for Kafka v2.8.1 to > mitigate CVE-2021-44228 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (KAFKA-13536) Log4J2 Vulnerability zero-day exploit is going on. Will it impact kafka_2.12-2.3.0 version and do we need to upgrade?
Rajendra created KAFKA-13536: Summary: Log4J2 Vulnerability zero-day exploit is going on. Will it impact kafka_2.12-2.3.0 version and do we need to upgrade? Key: KAFKA-13536 URL: https://issues.apache.org/jira/browse/KAFKA-13536 Project: Kafka Issue Type: Bug Reporter: Rajendra -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (KAFKA-13537) Will kafka_2.12-2.3.0 version be impacted by new zero-day exploit going on since last friday?
Rajendra created KAFKA-13537: Summary: Will kafka_2.12-2.3.0 version be impacted by new zero-day exploit going on since last friday? Key: KAFKA-13537 URL: https://issues.apache.org/jira/browse/KAFKA-13537 Project: Kafka Issue Type: Bug Environment: All Reporter: Rajendra h3. new zero-day exploit has been reported against the popular Log4J2 library which can allow an attacker to remotely execute code. h3. Affected Software A significant number of Java-based applications are using log4j as their logging utility and are vulnerable to this CVE. To the best of our knowledge, at least the following software may be impacted: * Apache Struts * Apache Solr * Apache Druid * Apache Flink * ElasticSearch * Flume * Apache Dubbo * Logstash * Kafka * Spring-Boot-starter-log4j2 Wondering if kafka_2.12-2.3.0 is impacted. I see below libraries. kafka-log4j-appender-2.3.0.jar log4j-1.2.17.jar scala-logging_2.12-3.9.0.jar slf4j-log4j12-1.7.26.jar -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (KAFKA-13536) Log4J2 Vulnerability zero-day exploit is going on. Will it impact kafka_2.12-2.3.0 version and do we need to upgrade?
[ https://issues.apache.org/jira/browse/KAFKA-13536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luke Chen resolved KAFKA-13536. --- Resolution: Duplicate > Log4J2 Vulnerability zero-day exploit is going on. Will it impact > kafka_2.12-2.3.0 version and do we need to upgrade? > - > > Key: KAFKA-13536 > URL: https://issues.apache.org/jira/browse/KAFKA-13536 > Project: Kafka > Issue Type: Bug >Reporter: Rajendra >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KAFKA-13537) Will kafka_2.12-2.3.0 version be impacted by new zero-day exploit going on since last friday?
[ https://issues.apache.org/jira/browse/KAFKA-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457805#comment-17457805 ] Luke Chen commented on KAFKA-13537: --- [~rajnaik] , thanks for reporting the issue. I've confirmed that Kafka is not affected by this CVE (or with low risk, compared to log4j 2.x versions). Please read my email reply here for more detail: [https://lists.apache.org/thread/lgbtvvmy68p0059yoyn9qxzosdmx4jdv] But we have a KIP to upgrade log4j to log4j2: KAFKA-9366 FYI > Will kafka_2.12-2.3.0 version be impacted by new zero-day exploit going on > since last friday? > - > > Key: KAFKA-13537 > URL: https://issues.apache.org/jira/browse/KAFKA-13537 > Project: Kafka > Issue Type: Bug > Environment: All >Reporter: Rajendra >Priority: Major > > h3. new zero-day exploit has been reported against the popular Log4J2 library > which can allow an attacker to remotely execute code. > h3. Affected Software > A significant number of Java-based applications are using log4j as their > logging utility and are vulnerable to this CVE. To the best of our knowledge, > at least the following software may be impacted: > * Apache Struts > * Apache Solr > * Apache Druid > * Apache Flink > * ElasticSearch > * Flume > * Apache Dubbo > * Logstash > * Kafka > * Spring-Boot-starter-log4j2 > Wondering if kafka_2.12-2.3.0 is impacted. I see below libraries. > kafka-log4j-appender-2.3.0.jar log4j-1.2.17.jar > scala-logging_2.12-3.9.0.jar slf4j-log4j12-1.7.26.jar > > > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KAFKA-13535) Workaround for mitigating CVE-2021-44228 Kafka
[ https://issues.apache.org/jira/browse/KAFKA-13535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457813#comment-17457813 ] Luke Chen commented on KAFKA-13535: --- [~vijaykaali811] , some update: log4j-1.x.x is not completely safe from this CVE. But as long as you're using Kafka, and not setting the log4j jms configuration: *TopicBindingName* or *TopicConnectionFactoryBindingName* to something that JNDI can handle, ex: "ldap://host:port/a"; (usually we won't set this kind of name), it is safe! > Workaround for mitigating CVE-2021-44228 Kafka > --- > > Key: KAFKA-13535 > URL: https://issues.apache.org/jira/browse/KAFKA-13535 > Project: Kafka > Issue Type: Bug >Affects Versions: 2.8.1 >Reporter: Akansh Shandilya >Priority: Major > > Kafka v2.8.1 uses log4j v1.x . Please review following information : > > Is Kafka v2.8.1 impacted by CVE-2021-44228? > If yes, is there any workaround/recommendation available for Kafka v2.8.1 to > mitigate CVE-2021-44228 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [kafka] guozhangwang commented on a change in pull request #11581: KAFKA-13522: add position tracking and bounding to IQv2
guozhangwang commented on a change in pull request #11581:
URL: https://github.com/apache/kafka/pull/11581#discussion_r767034399
##
File path:
streams/src/main/java/org/apache/kafka/streams/state/internals/CachingKeyValueStore.java
##
@@ -107,10 +107,10 @@ private void putAndMaybeForward(final
ThreadCache.DirtyEntry entry,
// we can skip flushing to downstream as well as writing to
underlying store
if (rawNewValue != null || rawOldValue != null) {
// we need to get the old values if needed, and then put to
store, and then flush
-wrapped().put(entry.key(), entry.newValue());
-
final ProcessorRecordContext current = context.recordContext();
context.setRecordContext(entry.entry().context());
+wrapped().put(entry.key(), entry.newValue());
Review comment:
You are right! This is a good fix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [kafka] cmccabe merged pull request #11577: KAFKA-13515: Fix KRaft config validation issues
cmccabe merged pull request #11577: URL: https://github.com/apache/kafka/pull/11577 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] jetlyg commented on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
jetlyg commented on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991704123 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] dajac commented on pull request #11571: KAFKA-13496: add reason to LeaveGroupRequest
dajac commented on pull request #11571: URL: https://github.com/apache/kafka/pull/11571#issuecomment-991664350 @jeffkbkim That's right. We have to bump the version of both the request and the response. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] cmccabe closed pull request #11544: MINOR: some code cleanups in the controller
cmccabe closed pull request #11544: URL: https://github.com/apache/kafka/pull/11544 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] omkreddy closed pull request #11507: Terminating process due to signal SIGTERM
omkreddy closed pull request #11507: URL: https://github.com/apache/kafka/pull/11507 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] vvcephei commented on a change in pull request #11581: KAFKA-13522: add position tracking and bounding to IQv2
vvcephei commented on a change in pull request #11581:
URL: https://github.com/apache/kafka/pull/11581#discussion_r767028987
##
File path:
streams/src/main/java/org/apache/kafka/streams/state/internals/StoreQueryUtils.java
##
@@ -62,4 +71,28 @@ public static void updatePosition(
position.withComponent(meta.topic(), meta.partition(),
meta.offset());
}
}
+
+public static boolean isPermitted(
Review comment:
I was hesitant to add anything extra to the Position class, but there's
no particular reason for it.
##
File path:
streams/src/test/java/org/apache/kafka/streams/integration/utils/IntegrationTestUtils.java
##
@@ -125,22 +128,81 @@
final long deadline = start + DEFAULT_TIMEOUT;
do {
+if (Thread.currentThread().isInterrupted()) {
+fail("Test was interrupted.");
+}
final StateQueryResult result = kafkaStreams.query(request);
-if (result.getPartitionResults().keySet().containsAll(partitions)
-|| result.getGlobalResult() != null) {
+if (result.getPartitionResults().keySet().containsAll(partitions))
{
return result;
} else {
-try {
-Thread.sleep(100L);
-} catch (final InterruptedException e) {
-throw new RuntimeException(e);
-}
+sleep(100L);
}
} while (System.currentTimeMillis() < deadline);
throw new TimeoutException("The query never returned the desired
partitions");
}
+/**
+ * Repeatedly runs the query until the response is valid and then return
the response.
+ *
+ * Validity in this case means that the response position is up to the
specified bound.
+ *
+ * Once position bounding is generally supported, we should migrate tests
to wait on the
+ * expected response position.
+ */
+public static StateQueryResult iqv2WaitForResult(
Review comment:
Thanks!
##
File path:
streams/src/main/java/org/apache/kafka/streams/state/internals/CachingKeyValueStore.java
##
@@ -107,10 +107,10 @@ private void putAndMaybeForward(final
ThreadCache.DirtyEntry entry,
// we can skip flushing to downstream as well as writing to
underlying store
if (rawNewValue != null || rawOldValue != null) {
// we need to get the old values if needed, and then put to
store, and then flush
-wrapped().put(entry.key(), entry.newValue());
-
final ProcessorRecordContext current = context.recordContext();
context.setRecordContext(entry.entry().context());
+wrapped().put(entry.key(), entry.newValue());
Review comment:
I'm not sure I follow; we always did set the context, we just did it
(incorrectly) between the `wrapped().put` and forwarding downstream. Why should
we do the `wrapped().put` with the wrong context and then forward with the
right context?
Taking your example sequence, the correct offset for record `A` is 0.
The old behavior was that we would do `wrapped().put(A)` with offset 2 and
then forward `A` with offset 0.
The new behavior is that we do `wrapped().put(A)` with offset 0 and then
forward `A` with offset 0.
There's no scenario in which we would forward A with offset 2.
##
File path:
streams/src/main/java/org/apache/kafka/streams/query/StateQueryResult.java
##
@@ -97,11 +97,15 @@ public void addResult(final int partition, final
QueryResult r) {
* prior observations.
*/
public Position getPosition() {
-Position position = Position.emptyPosition();
-for (final QueryResult r : partitionResults.values()) {
-position = position.merge(r.getPosition());
+if (globalResult != null) {
Review comment:
That's correct.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [kafka] wcarlson5 closed pull request #11570: KAFKA-12648: Wait for all threads to be on an empty topology before unsubscribing
wcarlson5 closed pull request #11570: URL: https://github.com/apache/kafka/pull/11570 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] svudutala-vmware commented on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
svudutala-vmware commented on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991209328 > Will this PR solve [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)? @soumiksamanta https://github.com/apache/kafka/blob/bd3038383265f7bb850c09fe0a74a48c5c2e6f99/gradle/dependencies.gradle#L78 should be upgraded to 2.15.0. log4j <= 2.14.0 all have this issue. Initially I thought log4j 1.x is not impacted but as per https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 it is. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] guozhangwang commented on a change in pull request #11591: KAFKA-12648: fix IllegalStateException in ClientState after removing topologies
guozhangwang commented on a change in pull request #11591:
URL: https://github.com/apache/kafka/pull/11591#discussion_r766944544
##
File path:
streams/src/test/java/org/apache/kafka/streams/processor/internals/assignment/ClientStateTest.java
##
@@ -406,12 +428,31 @@ public void
shouldAddTasksInOffsetSumsMapToPrevStandbyTasks() {
mkEntry(TASK_0_2, 100L)
);
client.addPreviousTasksAndOffsetSums("c1", taskOffsetSums);
-client.initializePrevTasks(Collections.emptyMap());
+client.initializePrevTasks(Collections.emptyMap(), false);
assertThat(client.prevStandbyTasks(), equalTo(mkSet(TASK_0_1,
TASK_0_2)));
assertThat(client.previousAssignedTasks(), equalTo(mkSet(TASK_0_1,
TASK_0_2)));
assertTrue(client.prevActiveTasks().isEmpty());
}
+@Test
+public void
shouldThrowWhenSomeOwnedPartitionsAreNotRecognizedWhenInitializingPrevStandbyTasks()
{
Review comment:
These two tests seem only be different on the test names, but they are
the same as the ones above (all lines within the function are the same)?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [kafka] priyavj08 removed a comment on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
priyavj08 removed a comment on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991672999 > Agree. After reconsidering the issue, I concluded that [CVE-2019-17571](https://github.com/advisories/GHSA-2qrg-x229-3v8q) is rather a minor issue; It is only problematic only when the user tries to use the `SocketServer` appender. hi @dongjinleekr, do we know if kafka 2.8.1 exposed to this vulnerability CVE-2021-44228? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] priyavj08 commented on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
priyavj08 commented on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991672999 > Agree. After reconsidering the issue, I concluded that [CVE-2019-17571](https://github.com/advisories/GHSA-2qrg-x229-3v8q) is rather a minor issue; It is only problematic only when the user tries to use the `SocketServer` appender. hi @dongjinleekr, do we know if kafka 2.8.1 exposed to this vulnerability CVE-2021-44228? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] jsancio closed pull request #11536: MINOR; Update merge script to work against Python3
jsancio closed pull request #11536: URL: https://github.com/apache/kafka/pull/11536 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] jsancio commented on a change in pull request #11593: KAFKA-13528: KRaft RegisterBroker should validate that the cluster ID matches
jsancio commented on a change in pull request #11593:
URL: https://github.com/apache/kafka/pull/11593#discussion_r766913504
##
File path:
metadata/src/test/java/org/apache/kafka/controller/ClusterControlManagerTest.java
##
@@ -84,6 +90,27 @@ public void testReplay() {
assertTrue(clusterControl.unfenced(1));
}
+@Test
+public void testRegistrationWithIncorrectClusterId() throws Exception {
+SnapshotRegistry snapshotRegistry = new SnapshotRegistry(new
LogContext());
+ClusterControlManager clusterControl = new ClusterControlManager(
+new LogContext(), "fPZv1VBsRFmnlRvmGcOW9w", new MockTime(0, 0, 0),
+snapshotRegistry, 1000,
+new StripedReplicaPlacer(new Random()), new
MockControllerMetrics());
+clusterControl.activate();
+try {
+clusterControl.registerBroker(new BrokerRegistrationRequestData().
+setClusterId("WIjw3grwRZmR2uOpdpVXbg").
+setBrokerId(0).
+setRack(null).
+
setIncarnationId(Uuid.fromString("0H4fUu1xQEKXFYwB1aBjhg")),
+123L,
+new FeatureMapAndEpoch(new FeatureMap(Collections.emptyMap()),
456L));
+Assertions.fail("Expected exception");
Review comment:
Did you consider using `Assertion.assertThrows`?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [kafka] svudutala-vmware edited a comment on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
svudutala-vmware edited a comment on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991209328 > Will this PR solve [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)? @soumiksamanta https://github.com/apache/kafka/blob/bd3038383265f7bb850c09fe0a74a48c5c2e6f99/gradle/dependencies.gradle#L78 should be upgraded to 2.15.0. log4j <= 2.14.0 all have this issue. Initially I thought log4j 1.x is not impacted but as per https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 it is. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] jsancio commented on pull request #11536: MINOR; Update merge script to work against Python3
jsancio commented on pull request #11536: URL: https://github.com/apache/kafka/pull/11536#issuecomment-991216638 Merged as https://github.com/apache/kafka/commit/0c01ab67a034a9454fdd1e0c791c56c5466d9ff4 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] omkreddy closed pull request #11506: kafka_2.10-0.10.0.0 shutdown
omkreddy closed pull request #11506: URL: https://github.com/apache/kafka/pull/11506 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] omkreddy commented on pull request #11506: kafka_2.10-0.10.0.0 shutdown
omkreddy commented on pull request #11506: URL: https://github.com/apache/kafka/pull/11506#issuecomment-991217959 Pls raise a Kafka JIRA (https://issues.apache.org/jira/projects/KAFKA/) for any issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] jetlyg removed a comment on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
jetlyg removed a comment on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991704123 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] vvcephei commented on pull request #11581: KAFKA-13522: add position tracking and bounding to IQv2
vvcephei commented on pull request #11581: URL: https://github.com/apache/kafka/pull/11581#issuecomment-991497134 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] hachikuji merged pull request #11503: KAFKA-13456: Tighten KRaft config checks/constraints
hachikuji merged pull request #11503: URL: https://github.com/apache/kafka/pull/11503 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] unverified-user commented on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
unverified-user commented on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-991705948 > > Will this PR solve [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)? > > @soumiksamanta > > https://github.com/apache/kafka/blob/bd3038383265f7bb850c09fe0a74a48c5c2e6f99/gradle/dependencies.gradle#L78 > > should be upgraded to 2.15.0. log4j <= 2.14.0 all have this issue. > Initially I thought log4j 1.x is not impacted but as per [apache/logging-log4j2#608 (comment)](https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126) it is. Thank you for sharing the comment. Isn't that comment for log4j v1 in general. kafka by default does not use JMS appender. Do you think it is impacted under the default configuration. Also refer to this post: https://lists.apache.org/thread/lgbtvvmy68p0059yoyn9qxzosdmx4jdv -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] ableegoldman commented on pull request #11591: KAFKA-12648: fix IllegalStateException in ClientState after removing topologies
ableegoldman commented on pull request #11591: URL: https://github.com/apache/kafka/pull/11591#issuecomment-991243851 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] ableegoldman merged pull request #11591: KAFKA-12648: fix IllegalStateException in ClientState after removing topologies
ableegoldman merged pull request #11591: URL: https://github.com/apache/kafka/pull/11591 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] omkreddy commented on pull request #11507: Terminating process due to signal SIGTERM
omkreddy commented on pull request #11507: URL: https://github.com/apache/kafka/pull/11507#issuecomment-991218175 Pls raise a Kafka JIRA (https://issues.apache.org/jira/projects/KAFKA/) for any issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] cmccabe commented on pull request #11544: MINOR: some code cleanups in the controller
cmccabe commented on pull request #11544: URL: https://github.com/apache/kafka/pull/11544#issuecomment-991372206 merged -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] cmccabe commented on pull request #11593: KAFKA-13528: KRaft RegisterBroker should validate that the cluster ID matches
cmccabe commented on pull request #11593: URL: https://github.com/apache/kafka/pull/11593#issuecomment-991360698 > What should be the broker behavior if cannot register because of an invalid cluster id? Looking at the current code it looks like the broker will continue to retry. InconsistentClusterIdException is not mark as retriable so I xxx think the broker should just shutdown, no? If the broker can't perform its initial registration, it will eventually shut itself down. This behavior is not specific to `InconsistentClusterIdException` -- if the broker can't register for ANY reason, it will shut down eventually. The length of time it will retry is configured by `initial.broker.registration.timeout.ms`. I agree that maybe we could shut down more rapidly here, but it seems simpler just to rely on the standard timeout. I don't think this is a common enough scenario to need a special case optimization. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] ableegoldman commented on a change in pull request #11591: KAFKA-12648: fix IllegalStateException in ClientState after removing topologies
ableegoldman commented on a change in pull request #11591:
URL: https://github.com/apache/kafka/pull/11591#discussion_r766945306
##
File path:
streams/src/test/java/org/apache/kafka/streams/processor/internals/assignment/ClientStateTest.java
##
@@ -406,12 +428,31 @@ public void
shouldAddTasksInOffsetSumsMapToPrevStandbyTasks() {
mkEntry(TASK_0_2, 100L)
);
client.addPreviousTasksAndOffsetSums("c1", taskOffsetSums);
-client.initializePrevTasks(Collections.emptyMap());
+client.initializePrevTasks(Collections.emptyMap(), false);
assertThat(client.prevStandbyTasks(), equalTo(mkSet(TASK_0_1,
TASK_0_2)));
assertThat(client.previousAssignedTasks(), equalTo(mkSet(TASK_0_1,
TASK_0_2)));
assertTrue(client.prevActiveTasks().isEmpty());
}
+@Test
+public void
shouldThrowWhenSomeOwnedPartitionsAreNotRecognizedWhenInitializingPrevStandbyTasks()
{
Review comment:
Ah, whoops, yeah they used to differ but I had to take that line out --
I'll remove the duplicate tests
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [kafka] guozhangwang commented on pull request #11589: MINOR: update log and method name
guozhangwang commented on pull request #11589: URL: https://github.com/apache/kafka/pull/11589#issuecomment-991249843 Re-trigger the jenkins jobs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] vvcephei merged pull request #11581: KAFKA-13522: add position tracking and bounding to IQv2
vvcephei merged pull request #11581: URL: https://github.com/apache/kafka/pull/11581 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
