Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #2264

[Apache Jenkins Server]

See 

Re: [PR] Added a blog entry for 3.6.0 release [kafka-site]

[via GitHub]

satishd commented on code in PR #547:
URL: https://github.com/apache/kafka-site/pull/547#discussion_r1349603237


##
blog.html:
##
@@ -22,6 +22,146 @@
 
 
 Blog
+
+
+
+Apache 
Kafka 3.6.0 Release Announcement
+
+08 Oct 2023 - Satish Duggana (https://twitter.com/0xeed";>@SatishDuggana)

Review Comment:
   I will update the release date with the date the release announcement is 
made.



-- 
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: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] MINOR Update default docs point to 3.6.0 release docs [kafka-site]

[via GitHub]

satishd commented on code in PR #556:
URL: https://github.com/apache/kafka-site/pull/556#discussion_r1349567200


##
downloads.html:
##
@@ -6,12 +6,41 @@

 Download
 
-3.5.1 is the latest release. The current stable version is 3.5.1
+3.6.0 is the latest release. The current stable version is 3.6.0
 
 
 You can verify your download by following these https://www.apache.org/info/verification.html";>procedures and using 
these https://downloads.apache.org/kafka/KEYS";>KEYS.
 
 
+
+3.6.0
+
+
+Released Oct 7, 2023
+
+
+https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html";>Release 
Notes

Review Comment:
   I kept 3.5.1 still with `downloads.apache.org` as that is the latest release 
for 3.5 and it may have some updates later. We can change it to 
`archive.apache.org` once we decide we will not have any updates on 3.5. 
   
   https://www.apache.org/legal/release-policy.html#when-to-archive
   ```
   downloads.apache.org should contain the latest release in each branch that 
is currently under development. When development ceases on a version branch, 
releases of that branch should be removed from the project's download directory.
   ```
   
   



-- 
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: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] MINOR Update default docs point to 3.6.0 release docs [kafka-site]

[via GitHub]

satishd commented on code in PR #556:
URL: https://github.com/apache/kafka-site/pull/556#discussion_r1349567200


##
downloads.html:
##
@@ -6,12 +6,41 @@

 Download
 
-3.5.1 is the latest release. The current stable version is 3.5.1
+3.6.0 is the latest release. The current stable version is 3.6.0
 
 
 You can verify your download by following these https://www.apache.org/info/verification.html";>procedures and using 
these https://downloads.apache.org/kafka/KEYS";>KEYS.
 
 
+
+3.6.0
+
+
+Released Oct 7, 2023
+
+
+https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html";>Release 
Notes

Review Comment:
   I kept 3.5.1 still with `downloads.apache.org` as that is the latest release 
for 3.5.1 and it may have some updates later. We can change it to 
`archive.apache.org` once we decide we will not have any updates on 3.5. 
   
   https://www.apache.org/legal/release-policy.html#when-to-archive
   ```
   downloads.apache.org should contain the latest release in each branch that 
is currently under development. When development ceases on a version branch, 
releases of that branch should be removed from the project's download directory.
   ```
   
   



-- 
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: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] MINOR Update default docs point to 3.6.0 release docs [kafka-site]

[via GitHub]

divijvaidya commented on code in PR #556:
URL: https://github.com/apache/kafka-site/pull/556#discussion_r1349564824


##
downloads.html:
##
@@ -6,12 +6,41 @@

 Download
 
-3.5.1 is the latest release. The current stable version is 3.5.1
+3.6.0 is the latest release. The current stable version is 3.6.0
 
 
 You can verify your download by following these https://www.apache.org/info/verification.html";>procedures and using 
these https://downloads.apache.org/kafka/KEYS";>KEYS.
 
 
+
+3.6.0
+
+
+Released Oct 7, 2023
+
+
+https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html";>Release 
Notes

Review Comment:
   Please move 3.5 artefacts to archive links as well.



-- 
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: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] MINOR Update default docs point to 3.6.0 release docs [kafka-site]

[via GitHub]

satishd commented on code in PR #556:
URL: https://github.com/apache/kafka-site/pull/556#discussion_r1349552314


##
downloads.html:
##
@@ -6,12 +6,41 @@

 Download
 
-3.5.1 is the latest release. The current stable version is 3.5.1
+3.6.0 is the latest release. The current stable version is 3.6.0
 
 
 You can verify your download by following these https://www.apache.org/info/verification.html";>procedures and using 
these https://downloads.apache.org/kafka/KEYS";>KEYS.
 
 
+
+3.6.0
+
+
+Released Oct 7, 2023
+
+
+https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html";>Release 
Notes

Review Comment:
   Good catch! Updated with the latest commit.



-- 
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: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Re: [DISCUSS] KIP-986: Cross-Cluster Replication

[Greg Harris]

Hello hudeqi,

I apologize if the KIP and discussion have diverged, as I've been
trying to add detail rather than propose changes.

> Why can't we use the follower fetch protocol?

What you've described sounds like a very reasonable implementation of
CCR. I purposely have not specified any implementation details so far
and have been focusing only on the user-facing semantics of the
feature. You are of course welcome to add details of how the
follower-fetch implementation would work to the KIP.

I think maybe this wording in the KIP was ambiguous: "Are not eligible
for fetch-from-follower on the source cluster". I clarified the
justification for this earlier in Tom's point D3. But to make the
statement itself more clear:

Consumers on the source cluster will not see a cross-cluster leader or
followers as valid replicas to fetch from for load-sharing or latency
optimization. Consumers on the target cluster will see the
cross-cluster followers as valid replicas to fetch from, as they will
appear as normal replicas. This was only meant to describe the
relationship of the remote replicas with Consumers, not with each
other.

I hope this is more clear.
Greg

On Sat, Oct 7, 2023 at 1:38 AM hudeqi <16120...@bjtu.edu.cn> wrote:
>
> Hi, Greg.
>
> After reading this KIP and your discussion, I feel that it is very divergent. 
> I can only start from one of them:
> Why can't we use the follower fetch protocol? The leader of the target 
> cluster topic partition can be treated as the follower of the source cluster 
> topic partition leader, and the fetched data is directly appended to the 
> local log (the remote fetch thread is inherited to the follower fetch thread, 
> thereby retaining the offset of the log), so that consumer/ producer client 
> can be omitted. Of course, this is just data replication. I may have to think 
> more about group offset/acl/config replication.
>
> best,
> hudeqi

[jira] [Created] (KAFKA-15564) Kafka 3.5.1 Mirror Maker 2 not translating the wrong offsets in destination

[Hemanth Savasere (Jira)]

Hemanth Savasere created KAFKA-15564:


 Summary: Kafka 3.5.1 Mirror Maker 2 not translating the wrong 
offsets in destination 
 Key: KAFKA-15564
 URL: https://issues.apache.org/jira/browse/KAFKA-15564
 Project: Kafka
  Issue Type: Bug
  Components: mirrormaker
Affects Versions: 3.5.1
Reporter: Hemanth Savasere
 Attachments: MM2 3.5.1 Logs.txt, docker-compose.yml, mm2.properties

Issue : Mirror Maker 2 not replicating the proper consumer group offsets when 
replication happens from source to destination kafka brokers


Steps to Reproduce :
# 1. Created 2 Kafka clusters locally using the attached docker-compose.yml 
file. Was using the confluent platform 7.2.1 docker images
# 2. Had added the below section to create 20 topics produce randomly 1000 to 
2000 messages in each topic, and then consume the same messages using 
consumer-groups.   
{code:java}
/etc/confluent/docker/run &
sleep 20
for i in {1..20}; do
  kafka-topics --create --bootstrap-server kafka-1:9092 
--replication-factor 1 --partitions 1 --topic topic$$i
done
for i in {1..20}; do
  num_msgs=$$(shuf -i 1000-2000 -n 1)
  seq 1 $$num_msgs | kafka-console-producer --broker-list kafka-1:9092 
--topic topic$$i
done
for i in {1..20}; do
  timeout 10 kafka-console-consumer --bootstrap-server kafka-1:9092 
--topic topic$$i --group consumer-group$$i
done
wait 
{code}
3. Ran the Mirror Maker 2 using the connect-mirror-maker.sh script after 
downloading the Kafka 3.5.1 release binaries. Verified the latest version was 
running and commitID 2c6fb6c54472e90a was shown in attached MM2 logs file.   




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Re: [DISCUSS] KIP-986: Cross-Cluster Replication

[hudeqi]

Hi, Greg.

After reading this KIP and your discussion, I feel that it is very divergent. I 
can only start from one of them:
Why can't we use the follower fetch protocol? The leader of the target cluster 
topic partition can be treated as the follower of the source cluster topic 
partition leader, and the fetched data is directly appended to the local log 
(the remote fetch thread is inherited to the follower fetch thread, thereby 
retaining the offset of the log), so that consumer/ producer client can be 
omitted. Of course, this is just data replication. I may have to think more 
about group offset/acl/config replication.

best,
hudeqi