Skip to content

more test#228

Closed
jinxing64 wants to merge 4 commits into
apache:trunkfrom
jinxing64:trunk
Closed

more test#228
jinxing64 wants to merge 4 commits into
apache:trunkfrom
jinxing64:trunk

Conversation

@jinxing64

Copy link
Copy Markdown

No description provided.

@asfbot

asfbot commented Sep 21, 2015

Copy link
Copy Markdown

kafka-trunk-git-pr #460 FAILURE
Looks like there's a problem with this pull request

@ijuma

ijuma commented Sep 22, 2015

Copy link
Copy Markdown
Member

Hi, can you please close this PR?

@jinxing64 jinxing64 closed this Nov 12, 2015
@jinxing64 jinxing64 reopened this Nov 12, 2015
@jinxing64 jinxing64 closed this Nov 12, 2015
jsancio pushed a commit to jsancio/kafka that referenced this pull request Aug 6, 2019
We have been a bit conservative about finding tierable segments. We always exclude the last candidate segment, as it might contain offsets that are not tierable. This patch makes this logic more accurate. We now have logic to figure out whether such untierable offsets are indeed in the last candidate segment.
efeg added a commit to efeg/kafka that referenced this pull request Jan 29, 2020
wyuka pushed a commit to wyuka/kafka that referenced this pull request Jan 21, 2022
… been refreshed for a long time (apache#228)

This patch adds a config li.client.cluster.metadata.expire.time.ms which controls the max time cluster metadata can remain unchanged. On NetworkClient.poll, if this timeout has been reached and the client has tried half of the nodes in the original cached node set and failed, it will try to resolve the bootstrap servers again and use the newly resolved nodes to pick a leastLoadedNode to send updateMetadataRequest.

This is to avoid following two scenarios:

consumer has been idle for a long time, and whole cluster has been swapped. This case, all the cached nodes are invalid and resolve bootstrap is needed.
consumer hasn't refreshed metadata for a long time and some brokers in the cluster had been moved to another cluster, and the client randomly picks up the moved broker to send md request and get a response for a different cluster. In this case, we simply reject the stale md response and resolve bootstrap when conditions are met.
TICKET =
LI_DESCRIPTION = LIKAFKA-40759,
EXIT_CRITERIA = MANUAL this is not going to merged with upstream

Co-authored-by: Ke Hu <kehu@kehu-mn2.linkedin.biz>
udaynpusa pushed a commit to mapr/kafka that referenced this pull request Jan 30, 2024
fvaleri pushed a commit to fvaleri/kafka that referenced this pull request Jul 21, 2026
…e#228)

* Revert "Merge pull request apache#161 from showuon/cl3_ut"

This reverts commit 55efc8d, reversing
changes made to 1c8b6d3.

* Revert "Merge pull request apache#155 from showuon/cl3_share_auto_create"

This reverts commit 05f8874, reversing
changes made to 143e6cc.

* MINOR: Cleanups in Tools Module (3/n) (apache#20332)

This PR aims at cleaning up the tools module further by getting rid of
some extra code which can be replaced by `record`

Reviewers: Chia-Ping Tsai <chia7712@gmail.com>

* MINOR: kafka-stream-groups.sh should fail quickly if the partition leader is unavailable (apache#20271)

This PR applies the same partition leader check for `StreamsGroupCommand` as
`ShareGroupCommand`  and `ConsumerGroupCommand` to avoid the command
execution timeout.

Reviewers: Lucas Brutschy <lucasbru@apache.org>

* KAFKA-19662: Allow resetting offset for unsubscribed topic in kafka-share-groups.sh (apache#20453)

The `kafka-share-groups.sh` tool checks whether a topic already has a
start-offset in the share group when resetting offsets. This is not
necessary. By removing the check, it is possible to set a start offset
for a topic which has not yet but will be subscribed in the future, thus
initialising the consumption point.

There is still a small piece of outstanding work to do with resetting
the offset for a non-existent group which should also create the group.
A subsequent PR will be used to address that.

Reviewers: Jimmy Wang <48462172+JimmyWang6@users.noreply.github.com>,
Lan Ding <isDing_L@163.com>, Apoorv Mittal <apoorvmittal10@gmail.com>

* KAFKA-19662: Reset share group offsets for unsubscribed topics (apache#20708)

This PR allows the kafka-share-groups.sh --reset-offsets tool to be used
to set offsets for topics which are not currently subscribed in a share
group. It also works if the share group does not yet exist. This brings
the capability in line with the equivalent function in
Kafka-consumer-groups.sh. The primary purpose is to allow offsets to be
set before the share group is first used as a way of initialising in a
known state.

Reviewers: Jimmy Wang <48462172+JimmyWang6@users.noreply.github.com>,
 Kuan-Po Tseng <brandboat@gmail.com>, Apoorv Mittal
 <apoorvmittal10@gmail.com>

---------

Co-authored-by: Sanskar Jhajharia <sjhajharia@confluent.io>
Co-authored-by: jimmy <wangzhiwang611@gmail.com>
Co-authored-by: Andrew Schofield <aschofield@confluent.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants