Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPARK-23747][Structured Streaming] Add EpochCoordinator unit tests #20983

Closed
wants to merge 5 commits into from
Closed

[SPARK-23747][Structured Streaming] Add EpochCoordinator unit tests #20983

wants to merge 5 commits into from

Conversation

spaced4ndy
Copy link

What changes were proposed in this pull request?

Unit tests for EpochCoordinator that test correct sequencing of committed epochs. Several tests are ignored since they test functionality implemented in SPARK-23503 which is not yet merged, otherwise they fail.

@spaced4ndy
Copy link
Author

@jose-torres this PR is ready for a review

Copy link
Contributor

@jose-torres jose-torres left a comment

Choose a reason for hiding this comment

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

Generally looks good. @tdas

makeSynchronousCall()

verifyCommit(startEpoch)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd suggest adding test cases where all but one writer partition has committed, or all but one reader partition has reported an offset. In those cases we should verify that the StreamWriter and query commits haven't happened.

setWriterPartitions(2)
setReaderPartitions(2)

val epochs = startEpoch to (startEpoch + 1)
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a personal preference thing, but I think it might be more readable to just use the raw numbers. Something like:

commitPartitionEpoch(0, 1)
commitPartitionEpoch(1, 1)
[...]
commitPartitionEpoch(0, 2)
commitPartitionEpoch(1, 2)
[...]

verifyCommitsInOrderOf(1, 2)

Copy link
Author

Choose a reason for hiding this comment

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

I agree that it would be more readable, however the fact that we test for the start epoch first might be not as obvious then since it'd be hardcoded in before. Still pretty obvious though I guess.. and probably there will be no need to change start epoch in tests so hardcoding it is fine, and readability would increase. Will change this

@spaced4ndy
Copy link
Author

spaced4ndy commented Apr 10, 2018

@jose-torres ready for a review

Copy link
Contributor

@jose-torres jose-torres left a comment

Choose a reason for hiding this comment

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

LGTM


makeSynchronousCall()

verifyCommitHasntHappened(1)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: maybe verifyNoCommitFor

Copy link
Contributor

@tdas tdas Apr 10, 2018

Choose a reason for hiding this comment

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

+1
verifyNoCommitFor is less verbose. will merge as soon as this is changed.

Copy link
Author

Choose a reason for hiding this comment

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

@tdas
Copy link
Contributor

tdas commented Apr 12, 2018

jenkins ok to test

@tdas
Copy link
Contributor

tdas commented Apr 12, 2018

jenkins test this please

@SparkQA
Copy link

SparkQA commented Apr 12, 2018

Test build #89297 has finished for PR 20983 at commit 89a1e11.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Apr 13, 2018

Test build #89324 has finished for PR 20983 at commit 8fa609c.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@spaced4ndy
Copy link
Author

@tdas @jose-torres should we merge this now that it passes tests and test SPARK-23503 changes?

@tdas
Copy link
Contributor

tdas commented Apr 17, 2018

Yeah. Merging this to master.

@tdas
Copy link
Contributor

tdas commented Apr 17, 2018

@jose-torres Should I cherry-pick it to 2.3 as well??

@asfgit asfgit closed this in 05ae747 Apr 17, 2018
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.

4 participants