Skip to content

Conversation

@apilloud
Copy link
Member

@apilloud apilloud commented Mar 9, 2018

Attempted metrics are not optional, they should always be returned. Committed metrics are a close enough approximation for attempted. When attempted metrics are not supported, a UnsupportedOperationException should be thrown rather then returning null. See:

* Return the value of this metric across all attempts of executing all parts of the pipeline.


Follow this checklist to help us incorporate your contribution quickly and easily:

  • Make sure there is a JIRA issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes.
  • Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.
  • Write a pull request description that is detailed enough to understand:
    • What the pull request does
    • Why it does it
    • How it does it
    • Why this approach
  • Each commit in the pull request should have a meaningful subject line and body.
  • Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
  • If this contribution is large, please file an Apache Individual Contributor License Agreement.

@apilloud apilloud changed the title BEAM-3803: Dataflow runner must supply attempted metrics BEAM-3803: Dataflow runner implements metrics contract Mar 9, 2018
@kennknowles
Copy link
Member

Strong agreement. If you have committed metrics, that number is clearly within spec for attempted metrics (which can be pretty much any value at all, when you get down to it).

public T committed() {
T committed = committedInternal();
if (committed == null) {
throw new UnsupportedOperationException("This runner does not currently support committed"
Copy link
Member

Choose a reason for hiding this comment

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

I'm not so keen on the use of exception instead of null. If something is explicitly optional @Nullable seems reasonable (insert standard rant about how Optional is a better choice but Java screwed it up and Guava is shaded).

I would imagine that changes to this class would just remove @Nullable from attempted, then an additional static factory method like createCommitted(<just committed value>) that populates both fields with that value, createAttempted(<just attempted value>) that leaves committed null and create(<both not nullable>). Incidentally the existing create method seems broken as it fails to mark them as @Nullable. When we plug in the checker framework that should be caught.

Copy link
Member

Choose a reason for hiding this comment

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

I see - the javadoc tells you to do this. That sucks. Want to fix the javadoc to have this better spec?

Copy link
Member

Choose a reason for hiding this comment

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

OK let's just make Dataflow match the spec and later change the spec to be good.

@apilloud
Copy link
Member Author

apilloud commented Mar 9, 2018

run java precommit

1 similar comment
@apilloud
Copy link
Member Author

run java precommit

@apilloud
Copy link
Member Author

run java gradle precommit

@kennknowles
Copy link
Member

run java precommit

@kennknowles kennknowles merged commit 20b13e9 into apache:master Mar 10, 2018
@apilloud apilloud deleted the dataflow-metrics branch March 12, 2018 16:09
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