Skip to content

KAFKA-2621; nextOffsetMetadata should be changed after rolling a new log segment#286

Closed
lindong28 wants to merge 2 commits into
apache:trunkfrom
lindong28:KAFKA-2621
Closed

KAFKA-2621; nextOffsetMetadata should be changed after rolling a new log segment#286
lindong28 wants to merge 2 commits into
apache:trunkfrom
lindong28:KAFKA-2621

Conversation

@lindong28

Copy link
Copy Markdown
Member

No description provided.

@lindong28

Copy link
Copy Markdown
Member Author

@becketqin Could you take a look?

Comment thread core/src/main/scala/kafka/log/Log.scala Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Maybe we can put this inside the roll()? Right after we add the new segment into the segments list. Because that is the actual place the base offset changes.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This makes sense to me. I think it is OK to possibly call do updateLogEndOffset() twice in the Log.append(). I have updated patch as you suggested.

@lindong28 lindong28 closed this Oct 8, 2015
@lindong28 lindong28 deleted the KAFKA-2621 branch October 13, 2015 00:48
wyuka pushed a commit to wyuka/kafka that referenced this pull request Mar 4, 2022
…er/consumer to network client (apache#286)

[LI-HOTFX] Allow passing client software name and version from producer/consumer to network client (apache#128)

TICKET = N/A
LI_DESCRIPTION = Add config to pass customized client name from producer/consumer to ApiVersionsRequest.

Starting from kafka 2.4, brokers are able to collect clients' version and name, see KIP-511 for more details.
With kafka 2.4 and linkedin-kafka-clients 10, we should make this name unique so that in future when collecting user metrics, we can distinguish supported clients from those using unsupported clients
EXIT_CRITERIA = N/A

Co-authored-by: Ke Hu <kehu@linkedin.com>
(cherry picked from commit 011ebf8)
fixing merge conflicts and tests
wyuka pushed a commit to wyuka/kafka that referenced this pull request Mar 28, 2022
…cer/consumer to network client (apache#286)

Original commit:
[LI-HOTFX] Allow passing client software name and version from producer/consumer to network client (apache#128)

TICKET = N/A
LI_DESCRIPTION = Add config to pass customized client name from producer/consumer to ApiVersionsRequest.

Starting from kafka 2.4, brokers are able to collect clients' version and name, see KIP-511 for more details.
With kafka 2.4 and linkedin-kafka-clients 10, we should make this name unique so that in future when collecting user metrics, we can distinguish supported clients from those using unsupported clients
EXIT_CRITERIA = N/A

Co-authored-by: Ke Hu <kehu@linkedin.com>
(cherry picked from commit 011ebf8)
fixing merge conflicts and tests
wyuka pushed a commit to wyuka/kafka that referenced this pull request Jun 16, 2022
…cer/consumer to network client (apache#286)

Original commit:
[LI-HOTFX] Allow passing client software name and version from producer/consumer to network client (apache#128)

TICKET = N/A
LI_DESCRIPTION = Add config to pass customized client name from producer/consumer to ApiVersionsRequest.

Starting from kafka 2.4, brokers are able to collect clients' version and name, see KIP-511 for more details.
With kafka 2.4 and linkedin-kafka-clients 10, we should make this name unique so that in future when collecting user metrics, we can distinguish supported clients from those using unsupported clients
EXIT_CRITERIA = N/A

Co-authored-by: Ke Hu <kehu@linkedin.com>
(cherry picked from commit 011ebf8)
fixing merge conflicts and tests
davide-armand pushed a commit to aiven/kafka that referenced this pull request Dec 1, 2025
jeqo added a commit to aiven/kafka that referenced this pull request Jan 16, 2026
traceyyoshima added a commit to traceyyoshima/kafka that referenced this pull request May 22, 2026
Single bulk apply of the Language Engine's IntelliJ-style format
profile across the kafka source tree. Pairs with the IntelliJ-real
control branch `intellij-formatting` for side-by-side comparison.

Engine state at apply time includes the following format fixes
landed against the language-engine repo:

  Pre-PR #11:
  - PR apache#275 multi-line // comment indent group
  - PR apache#276 BLANK_LINES_AROUND_CLASS + sibling no-op repair
  - PR apache#277 string-concat chain anchor preservation
  - PR apache#279 forward style through apply routes
  - PR apache#281 Result-tab line-number alignment
  - PR apache#282 spaces after return / throw / yield / instanceof
  - PR apache#283 chain-dot postfix preservation
  - PR apache#284 BlankLines sibling minimum.* conversion
  - PR apache#285 chain-dot single-anchor (N=1) preservation
  - PR apache#286 string-concat chain partial-cascade fix
  - PR apache#287 method-decl param re-align for misaligned source
  - PR apache#288 annotation-in-array-init indent

  Post-original-PR #11 (new in this re-apply):
  - PR apache#289 partial-cascade post-rewrite-anchor (4 shape fixes:
    chain-dot postfix follow-on, MI/NewClass close-paren cascade,
    ternary continuation, lambda body continuation)

Stats: 3101 files written, 0 failures, 2678 already-idempotent
files skipped (no_change). Corpus byte delta vs trunk: -510 bytes
(106275 insertions / 106785 deletions).
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.

2 participants