Skip to content

KAFKA-2341 Add standard deviation as metric#80

Closed
sebadiaz wants to merge 8 commits intoapache:trunkfrom
sebadiaz:trunk
Closed

KAFKA-2341 Add standard deviation as metric#80
sebadiaz wants to merge 8 commits intoapache:trunkfrom
sebadiaz:trunk

Conversation

@sebadiaz
Copy link
Copy Markdown

KAFKA-2341 Add standard deviation as metric

@asfbot
Copy link
Copy Markdown

asfbot commented Jul 16, 2015

kafka-trunk-git-pr #3 SUCCESS
This pull request looks good

@ijuma ijuma mentioned this pull request Jul 16, 2015
@guozhangwang
Copy link
Copy Markdown
Contributor

Hi @sebadiaz , could you rebase?

@sebadiaz
Copy link
Copy Markdown
Author

@guozhangwang rebase done

@guozhangwang
Copy link
Copy Markdown
Contributor

@sebadiaz Seems your rebasing does not take all the changes from apache trunk (there are 1330+ file changes from your patch).

@guozhangwang
Copy link
Copy Markdown
Contributor

test this

@asfbot
Copy link
Copy Markdown

asfbot commented Dec 21, 2016

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.11/318/
Test PASSed (JDK 8 and Scala 2.11).

@asfbot
Copy link
Copy Markdown

asfbot commented Dec 21, 2016

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.10/316/
Test PASSed (JDK 7 and Scala 2.10).

@asfbot
Copy link
Copy Markdown

asfbot commented Dec 21, 2016

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/317/
Test PASSed (JDK 8 and Scala 2.12).

public long eventCount;
public long lastWindowMs;
public double value;
public double secondValue;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of doing this, it may be better to have a subclass for the case where there are two values. Also, reset would have to reset secondValue too.

efeg added a commit to efeg/kafka that referenced this pull request Apr 29, 2020
…PartitionException upon topic creation and deletion. (apache#80)

TICKET =
LI_DESCRIPTION =
When does UnknownTopicOrPartitionException typically occur?
* Upon a topic creation, a follower broker of a new partition starts replica fetcher before the prospective leader broker of the new partition receives the leadership information from the controller. Apache Kafka has a an open issue about this (see KAFKA-6221)
* Upon a topic deletion, a follower broker of a to-be-deleted partition starts replica fetcher after the leader broker of the to-be-deleted partition processes the deletion information from the controller.
* As expected, clusters with frequent topic creation and deletion report UnknownTopicOrPartitionException with relatively higher frequency.

What is the impact?
* Exception tracking systems identify the error logs with UnknownTopicOrPartitionException as an exception. This results in a lot of noise for a transient issue that is expected to recover by itself and a natural process in Kafka due to its asynchronous state propagation.

Why not move it to a lower than warn-level log?
* Despite typically being a transient issue, UnknownTopicOrPartitionException may also indicate real issues if it doesn't fix itself after a short period of time. To ensure detection of such scenarios, this PR sets the log level to warn.

EXIT_CRITERIA = TICKET [KAFKA-6221]
@hachikuji
Copy link
Copy Markdown
Contributor

I'm going to close this due to inactivity. Note that this change will require a KIP since it affects the public metrics API: https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals. Please reopen if you have time to submit a proposal for this change.

@hachikuji hachikuji closed this Jun 7, 2020
smccauliff pushed a commit to smccauliff/kafka that referenced this pull request Oct 8, 2020
…PartitionException upon topic creation and deletion. (apache#80)

TICKET =
LI_DESCRIPTION =
When does UnknownTopicOrPartitionException typically occur?
* Upon a topic creation, a follower broker of a new partition starts replica fetcher before the prospective leader broker of the new partition receives the leadership information from the controller. Apache Kafka has a an open issue about this (see KAFKA-6221)
* Upon a topic deletion, a follower broker of a to-be-deleted partition starts replica fetcher after the leader broker of the to-be-deleted partition processes the deletion information from the controller.
* As expected, clusters with frequent topic creation and deletion report UnknownTopicOrPartitionException with relatively higher frequency.

What is the impact?
* Exception tracking systems identify the error logs with UnknownTopicOrPartitionException as an exception. This results in a lot of noise for a transient issue that is expected to recover by itself and a natural process in Kafka due to its asynchronous state propagation.

Why not move it to a lower than warn-level log?
* Despite typically being a transient issue, UnknownTopicOrPartitionException may also indicate real issues if it doesn't fix itself after a short period of time. To ensure detection of such scenarios, this PR sets the log level to warn.

EXIT_CRITERIA = TICKET [KAFKA-6221]
rustd pushed a commit to rustd/pranavfinaldemokafka that referenced this pull request Feb 9, 2024
…he#80)

Quickstart examples didn't produce any console output, since it was missing a logger implementation in the classpath.

Also some minor cleanups.

Tested by creating a test project and running the code.

Co-authored-by: Lucas Brutschy <lucasbru@users.noreply.github.com>
davide-armand pushed a commit to aiven/kafka that referenced this pull request Dec 1, 2025
This commit make it so that `ControlPlane` knows when a topic created or deleted or when a partition is created (including initial loading of these metadata). Some necessary refactoring made.
fvaleri added a commit to fvaleri/kafka that referenced this pull request Feb 6, 2026
Fix the preparing stuck when failback
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.

5 participants