b-goyal commented on PR #2:
URL: https://github.com/apache/kafka/pull/2#issuecomment-1997285130
This issue can be caused by a non-existing path but also a misunderstanding
from the config file. A short example will help the user.
--
This is an automated message from the Apache Git
b-goyal commented on PR #2:
URL: https://github.com/apache/kafka/pull/2#issuecomment-1997283060
This issue can be caused by a non-existing path but also a misunderstanding
from the config file. A short example will help the user.
--
This is an automated message from the Apache Git
b-goyal commented on PR #1:
URL: https://github.com/apache/kafka/pull/1#issuecomment-1997283063
Compiled and used fine. I had issues with the tests though.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL
b-goyal commented on PR #279:
URL: https://github.com/apache/kafka/pull/279#issuecomment-1997283302
Transient exception handling.
--
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
b-goyal commented on PR #282:
URL: https://github.com/apache/kafka/pull/282#issuecomment-1997283282
Add sanity test in kafkaConsumer for the timeouts. This is a followup ticket
for Kafka-2120.
--
This is an automated message from the Apache Git Service.
To respond to the message,
b-goyal commented on PR #18:
URL: https://github.com/apache/kafka/pull/18#issuecomment-1997283274
Changes to use hadoop-core-1.2.1.jar in hadoop-consumer
Changes to import from maven the packages needed to run hadoop-consumer in
HDFS
--
This is an automated message from the Apache
b-goyal commented on PR #221:
URL: https://github.com/apache/kafka/pull/221#issuecomment-1997283234
@hachikuji @ewencp I found this problem when adding new consumer to mirror
maker which commits offset in the rebalance callback. It is not clear to me why
we are triggering rebalance for
b-goyal commented on PR #199:
URL: https://github.com/apache/kafka/pull/199#issuecomment-1997283180
Small clarification to docs. Current behaviour could confuse when doing
something like:
consumer.seekToEnd()
consumer.send(msg)
consumer.poll() //would return msg as seek evaluates
b-goyal commented on PR #21:
URL: https://github.com/apache/kafka/pull/21#issuecomment-1997283175
This patch extends git ignore patterns to all build and .gradle dirs
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and
b-goyal commented on PR #10:
URL: https://github.com/apache/kafka/pull/10#issuecomment-1997283124
This adds another version of `commitOffsets` that takes the offsets to
commit as a parameter.
Without this change, getting correct user code is very hard. Despite
kafka's at-least-once
b-goyal commented on PR #7:
URL: https://github.com/apache/kafka/pull/7#issuecomment-1997283100
I'm working on an application that needs the throughput offered by an async
producer but also needs to handle send failures gracefully like a sync
producer. I modified the ProducerSendThread so
b-goyal commented on PR #254:
URL: https://github.com/apache/kafka/pull/254#issuecomment-1997283126
…plicaCount
--
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
b-goyal commented on PR #6:
URL: https://github.com/apache/kafka/pull/6#issuecomment-1997283088
While I was studying how MappedByteBuffer works, I saw a sharing runtime
exception on Windows. I applied what I learned to generate a patch which uses
an internal open JDK API to solve this
b-goyal commented on PR #5:
URL: https://github.com/apache/kafka/pull/5#issuecomment-1997283087
KAFKA-948
When the broker which is the leader for a partition is down, the ISR list in
the LeaderAndISR path is updated. But if the broker , which is not a leader of
the partition is down,
b-goyal commented on PR #138:
URL: https://github.com/apache/kafka/pull/138#issuecomment-1997281261
The commit here improves the logging in SimpleConsumer to log the real
reason why a reconnect was attempted. Relates to
https://issues.apache.org/jira/browse/KAFKA-2221.
The same
b-goyal commented on PR #90:
URL: https://github.com/apache/kafka/pull/90#issuecomment-1997281238
The first 4 commits are adapted from changes that have been done to the
Spark version and the last one is the feature that @gwenshap asked for.
--
This is an automated message from the
b-goyal commented on PR #264:
URL: https://github.com/apache/kafka/pull/264#issuecomment-1997281213
@hachikuji @MayureshGharat @jjkoshy Thoughts?
--
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
b-goyal commented on PR #36:
URL: https://github.com/apache/kafka/pull/36#issuecomment-1997281199
In log4j.properties, a property kafka.logs.dir was defined. However,
modifying this property has no effect because log4j.properties does not support
variable substitution in this manner.
b-goyal commented on PR #282:
URL: https://github.com/apache/kafka/pull/282#issuecomment-1997281191
Add sanity test in kafkaConsumer for the timeouts. This is a followup ticket
for Kafka-2120.
--
This is an automated message from the Apache Git Service.
To respond to the message,
b-goyal commented on PR #54:
URL: https://github.com/apache/kafka/pull/54#issuecomment-1997281108
gradle files, tiny footprint.lets have it in.thanks
--
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
b-goyal commented on PR #141:
URL: https://github.com/apache/kafka/pull/141#issuecomment-1997281107
Migration is done but this PR will need to be rebased on #110. I have copied
some code (ef669a5) for now.
I'd appreciate feedback on it mainly around how I handle things in the
b-goyal commented on PR #287:
URL: https://github.com/apache/kafka/pull/287#issuecomment-1997281226
Log warning message before truncating log in order to
display right offset value for the truncated log.
--
This is an automated message from the Apache Git Service.
To respond to the
b-goyal commented on PR #199:
URL: https://github.com/apache/kafka/pull/199#issuecomment-1997281080
Small clarification to docs. Current behaviour could confuse when doing
something like:
consumer.seekToEnd()
consumer.send(msg)
consumer.poll() //would return msg as seek evaluates
b-goyal commented on PR #103:
URL: https://github.com/apache/kafka/pull/103#issuecomment-1997281237
Let's say every consumer in a group has session timeout s. Currently, if a
consumer leaves the group, the worst case time to stabilize the group is 2s (s
to detect the consumer failure + s
b-goyal commented on PR #279:
URL: https://github.com/apache/kafka/pull/279#issuecomment-1997281218
Transient exception handling.
--
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
b-goyal commented on PR #7:
URL: https://github.com/apache/kafka/pull/7#issuecomment-1997281006
I'm working on an application that needs the throughput offered by an async
producer but also needs to handle send failures gracefully like a sync
producer. I modified the ProducerSendThread so
b-goyal commented on PR #18:
URL: https://github.com/apache/kafka/pull/18#issuecomment-1997281154
Changes to use hadoop-core-1.2.1.jar in hadoop-consumer
Changes to import from maven the packages needed to run hadoop-consumer in
HDFS
--
This is an automated message from the Apache
b-goyal commented on PR #5:
URL: https://github.com/apache/kafka/pull/5#issuecomment-1997280991
KAFKA-948
When the broker which is the leader for a partition is down, the ISR list in
the LeaderAndISR path is updated. But if the broker , which is not a leader of
the partition is down,
b-goyal commented on PR #123:
URL: https://github.com/apache/kafka/pull/123#issuecomment-1997281121
console consumer writes to System.out, while (some) log4j loggers operate in
other threads.
This occasionally led to funky interleaved output which disrupted parsing of
consumed
b-goyal commented on PR #221:
URL: https://github.com/apache/kafka/pull/221#issuecomment-1997281124
@hachikuji @ewencp I found this problem when adding new consumer to mirror
maker which commits offset in the rebalance callback. It is not clear to me why
we are triggering rebalance for
b-goyal commented on PR #2:
URL: https://github.com/apache/kafka/pull/2#issuecomment-1997280966
This issue can be caused by a non-existing path but also a misunderstanding
from the config file. A short example will help the user.
--
This is an automated message from the Apache Git
b-goyal commented on PR #21:
URL: https://github.com/apache/kafka/pull/21#issuecomment-1997281081
This patch extends git ignore patterns to all build and .gradle dirs
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and
b-goyal commented on PR #254:
URL: https://github.com/apache/kafka/pull/254#issuecomment-1997281031
…plicaCount
--
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
b-goyal commented on PR #10:
URL: https://github.com/apache/kafka/pull/10#issuecomment-1997281026
This adds another version of `commitOffsets` that takes the offsets to
commit as a parameter.
Without this change, getting correct user code is very hard. Despite
kafka's at-least-once
b-goyal commented on PR #3:
URL: https://github.com/apache/kafka/pull/3#issuecomment-1997280978
Following https://issues.apache.org/jira/browse/KAFKA-826 I forked the code
and included fixes for 2 bugs I reported,
https://issues.apache.org/jira/browse/KAFKA-807 and
b-goyal commented on PR #6:
URL: https://github.com/apache/kafka/pull/6#issuecomment-1997280996
While I was studying how MappedByteBuffer works, I saw a sharing runtime
exception on Windows. I applied what I learned to generate a patch which uses
an internal open JDK API to solve this
b-goyal commented on PR #1:
URL: https://github.com/apache/kafka/pull/1#issuecomment-1997280964
Compiled and used fine. I had issues with the tests though.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL
[
https://issues.apache.org/jira/browse/KAFKA-16373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krish Vora updated KAFKA-16373:
---
Description:
KIP-1028: Docker Official Image for Apache Kafka:
dajac opened a new pull request, #15533:
URL: https://github.com/apache/kafka/pull/15533
This patch fixes a bug in the logic which decides when a full
ConsumerGroupHeartbeat response must be returned to the client. Prior to it,
the logic only relies on the `ownedTopicPartitions` field to
Krish Vora created KAFKA-16373:
--
Summary: Docker Official Image for Apache Kafka
Key: KAFKA-16373
URL: https://issues.apache.org/jira/browse/KAFKA-16373
Project: Kafka
Issue Type: New Feature
[
https://issues.apache.org/jira/browse/KAFKA-16372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haruki Okada updated KAFKA-16372:
-
Component/s: producer
(was: clients)
Priority: Minor (was: Major)
dajac commented on code in PR #15511:
URL: https://github.com/apache/kafka/pull/15511#discussion_r1524608939
##
clients/src/main/java/org/apache/kafka/clients/consumer/internals/HeartbeatRequestManager.java:
##
@@ -529,25 +530,18 @@ public ConsumerGroupHeartbeatRequestData
Haruki Okada created KAFKA-16372:
Summary: max.block.ms behavior inconsistency with javadoc and the
config description
Key: KAFKA-16372
URL: https://issues.apache.org/jira/browse/KAFKA-16372
Project:
msn-tldr closed pull request #15019: Fix so that a partition is retained, if
the another parititon on same…
URL: https://github.com/apache/kafka/pull/15019
--
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
[
https://issues.apache.org/jira/browse/KAFKA-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated KAFKA-16371:
-
Description:
Issue is reproducible with simple CLI tool -
[
https://issues.apache.org/jira/browse/KAFKA-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated KAFKA-16371:
-
Description:
Issue is reproducible with simple CLI tool -
[
https://issues.apache.org/jira/browse/KAFKA-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated KAFKA-16371:
-
Description:
Issue is reproducible with simple CLI tool -
[
https://issues.apache.org/jira/browse/KAFKA-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated KAFKA-16371:
-
Description:
Issue is reproducible with simple CLI tool -
[
https://issues.apache.org/jira/browse/KAFKA-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated KAFKA-16371:
-
Description:
Issue is reproducible with simple CLI tool -
[
https://issues.apache.org/jira/browse/KAFKA-16369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edoardo Comar updated KAFKA-16369:
--
Affects Version/s: 3.6.1
3.7.0
3.8.0
> Broker
[
https://issues.apache.org/jira/browse/KAFKA-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated KAFKA-16371:
-
Description:
Issue is reproducible with simple CLI tool -
[
https://issues.apache.org/jira/browse/KAFKA-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated KAFKA-16371:
-
Description:
Issue is reproducible with simple CLI tool -
[
https://issues.apache.org/jira/browse/KAFKA-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated KAFKA-16371:
-
Description:
Issue is reproducible with simple CLI tool -
mlowicki created KAFKA-16371:
Summary: Unstable committed offsets after triggering commits where
some metadata for some partitions are over the limit
Key: KAFKA-16371
URL:
[
https://issues.apache.org/jira/browse/KAFKA-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mlowicki updated KAFKA-16371:
-
Summary: Unstable committed offsets after triggering commits where metadata
for some partitions are
lucasbru commented on code in PR #15511:
URL: https://github.com/apache/kafka/pull/15511#discussion_r1524569366
##
clients/src/main/java/org/apache/kafka/clients/consumer/internals/HeartbeatRequestManager.java:
##
@@ -530,19 +530,12 @@ public ConsumerGroupHeartbeatRequestData
lucasbru commented on code in PR #15511:
URL: https://github.com/apache/kafka/pull/15511#discussion_r1524568814
##
clients/src/main/java/org/apache/kafka/clients/consumer/internals/MembershipManagerImpl.java:
##
@@ -889,43 +914,36 @@ private void transitionToStale() {
*/
viktorsomogyi merged PR #11982:
URL: https://github.com/apache/kafka/pull/11982
--
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:
dajac commented on code in PR #15511:
URL: https://github.com/apache/kafka/pull/15511#discussion_r1524430731
##
clients/src/main/java/org/apache/kafka/clients/consumer/internals/HeartbeatRequestManager.java:
##
@@ -529,25 +530,18 @@ public ConsumerGroupHeartbeatRequestData
[
https://issues.apache.org/jira/browse/KAFKA-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kaushik srinivas updated KAFKA-16370:
-
Issue Type: Wish (was: Improvement)
> offline rollback procedure from kraft mode to
[
https://issues.apache.org/jira/browse/KAFKA-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kaushik srinivas updated KAFKA-16370:
-
Issue Type: Improvement (was: Wish)
> offline rollback procedure from kraft mode to
kaushik srinivas created KAFKA-16370:
Summary: offline rollback procedure from kraft mode to zookeeper
mode.
Key: KAFKA-16370
URL: https://issues.apache.org/jira/browse/KAFKA-16370
Project: Kafka
[
https://issues.apache.org/jira/browse/KAFKA-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Divij Vaidya updated KAFKA-16073:
-
Fix Version/s: 3.6.2
(was: 3.6.1)
> Kafka Tiered Storage: Consumer Fetch
dajac commented on code in PR #15528:
URL: https://github.com/apache/kafka/pull/15528#discussion_r1524389411
##
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/GroupMetadataManager.java:
##
@@ -579,7 +579,7 @@ public List
describeGroups(
}
/**
-
showuon commented on PR #15523:
URL: https://github.com/apache/kafka/pull/15523#issuecomment-1996775024
If the root cause of the flaky test is the `ShutdownableThreadTest` is not
running, could we add `TestUtils.waitUntilTrue(() =>
cache.cleanerThread.isStarted)` before we invoke
[
https://issues.apache.org/jira/browse/KAFKA-16249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-16249.
-
Fix Version/s: 3.8.0
Resolution: Fixed
> Improve reconciliation state machine
>
[
https://issues.apache.org/jira/browse/KAFKA-15997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-15997.
-
Resolution: Fixed
This issue got resolved by https://issues.apache.org/jira/browse/KAFKA-16249.
[
https://issues.apache.org/jira/browse/KAFKA-15997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot reassigned KAFKA-15997:
---
Assignee: David Jacot (was: Ritika Reddy)
> Ensure fairness in the uniform assignor
>
dajac merged PR #15364:
URL: https://github.com/apache/kafka/pull/15364
--
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:
OmniaGM commented on PR #15103:
URL: https://github.com/apache/kafka/pull/15103#issuecomment-1996761545
I published another PR to move only the properties and their docs out of
core #15501
--
This is an automated message from the Apache Git Service.
To respond to the message, please log
kamalcph commented on PR #15523:
URL: https://github.com/apache/kafka/pull/15523#issuecomment-1996675858
Thanks for the review!
> If the cleaner thread wasn't even started, are our really testing correct
behaviour? For example, when we validate that cleaner shouldn't have deleted
301 - 371 of 371 matches
Mail list logo
