Skip to content

KAFKA-10097: Internalize checkpoint data#8820

Merged
mjsax merged 3 commits into
apache:trunkfrom
abbccdda:KAFKA-10097
Jun 7, 2020
Merged

KAFKA-10097: Internalize checkpoint data#8820
mjsax merged 3 commits into
apache:trunkfrom
abbccdda:KAFKA-10097

Conversation

@abbccdda

@abbccdda abbccdda commented Jun 6, 2020

Copy link
Copy Markdown
  • make checkpoint an internal data structure to avoid awkward passing around.
  • remove the possibility of getting a null checkpoint map

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@mjsax mjsax added the streams label Jun 6, 2020

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.

Do we need to set checkpointNeeded = false here?

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.

As above?

@mjsax mjsax left a comment

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.

Overall LGTM.

private Map<TopicPartition, Long> prepareClose(final boolean clean) {
final Map<TopicPartition, Long> checkpoint;
private void prepareClose(final boolean clean) {
// Reset any previously scheduled checkpoint.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

I think we could just reset any checkpoint at the beginning, so that we only do checkpointing if this call thinks so. @mjsax

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.

That should work.

if (clean && checkpoint != null) {
executeAndMaybeSwallow(clean, () -> stateMgr.checkpoint(checkpoint), "state manager checkpoint", log);
private void close(final boolean clean) {
if (clean && checkpointNeeded) {

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.

A if (clean) should be sufficient now

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Make sense

@mjsax

mjsax commented Jun 6, 2020

Copy link
Copy Markdown
Member

Retest this please.

@guozhangwang

Copy link
Copy Markdown
Contributor

test this

@guozhangwang guozhangwang left a comment

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.

Just one nit comment, otherwise LGTM!

private boolean commitNeeded = false;
private boolean commitRequested = false;

private boolean checkpointNeeded = false;

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.

Do we need two parameters here? Could we still just use one Map<TopicPartition, Long> checkpoint, and then in writeCheckpointIfNeed if it is not null write it and then set it to null.

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.

I actually had a similar thought, but I am torn though. Using two variables required to keep them "in sync" was is not great. However, using null is less explicit... Thus overall I am fine either way as both seems to provide the overall same good/bad ratio.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

A third option is Optional<Map<TopicPartition, Long>> which explicitly states the checkpoint is null. However, I think the benefit here is minimal, as checkpointNeeded sounds like a better state variable, than relying on the struct itself.

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.

Actually I'm not too concerned of relying on null to indicate no need to checkpoint, what I originally pointed out is that we are unnecessarily accumulating and then distributing checkpoints between task manager and task, which is already resolved in your PR. So I'd suggest we still just use a single nullable Map.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Cool

@guozhangwang

Copy link
Copy Markdown
Contributor

test this please

@guozhangwang

Copy link
Copy Markdown
Contributor

test this

@guozhangwang

Copy link
Copy Markdown
Contributor

test this

@guozhangwang

Copy link
Copy Markdown
Contributor

okay to test

1 similar comment
@guozhangwang

Copy link
Copy Markdown
Contributor

okay to test

@mjsax

mjsax commented Jun 6, 2020

Copy link
Copy Markdown
Member

Retest this please.

1 similar comment
@mjsax

mjsax commented Jun 6, 2020

Copy link
Copy Markdown
Member

Retest this please.

@mjsax
mjsax merged commit d4ef46c into apache:trunk Jun 7, 2020
mjsax pushed a commit that referenced this pull request Jun 7, 2020
Reviewers: Matthias J. Sax <matthias@confluent.io>, Guozhang Wang <guozhang@confluent.io>
@mjsax

mjsax commented Jun 7, 2020

Copy link
Copy Markdown
Member

Merged to trunk and cherry-picked to 2.6 branch.

ijuma added a commit to confluentinc/kafka that referenced this pull request Jun 8, 2020
Conflicts:
* build.gradle: take upstream changes regarding heap memory
configuration for the build.

* apache-github/trunk: (33 commits)
  MINOR: fix HTML markup (apache#8823)
  KAFKA-10012; Reduce overhead of strings in SelectorMetrics (apache#8684)
KAFKA-9216: Enforce internal config topic settings for Connect workers
during startup (apache#8270)
  KAFKA-10097: Internalize checkpoint data (apache#8820)
KAFKA-10033: Throw UnknownTopicOrPartitionException when modifying a
non-existent topic's config
MINOR: improve code encapsulation between StreamThread and TaskManager
(apache#8819)
  Fixing KAFKA-10094 (apache#8797)
KAFKA-9851: Revoking Connect tasks due to connectivity issues should
also clear the running assignment (apache#8804)
KAFKA-9840; Skip End Offset validation when the leader epoch is not
reliable (apache#8486)
  HOT_FIX: Update javadoc since imports added (apache#8817)
  KAFKA-8011: Fix flaky RegexSourceIntegrationTest (apache#8799)
KAFKA-9570: Define SSL configs in all worker config classes, not just
distributed (apache#8135)
KAFKA-10111: Make SinkTaskContext.errantRecordReporter() a default
method (apache#8814)
KAFKA-10110: Corrected potential NPE when null label value added to
KafkaMetricsContext (apache#8811)
MINOR: Change the order that Connect calls `config()` and `validate()`
to avoid validating if the required ConfigDef is null (apache#8810)
MINOR: fix backwards incompatibility in JmxReporter introduced by
KIP-606
  MINOR: Fix javadoc warnings (apache#8809)
  KAFKA-9441: Improve Kafka Streams task management (apache#8776)
  fix the broken links of streams javadoc (apache#8789)
KAFKA-10040; Make computing the PreferredReplicaImbalanceCount metric
more efficient (apache#8724)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants