Skip to content

Conversation

@XComp
Copy link
Contributor

@XComp XComp commented Mar 31, 2022

The writeValue calls close by default internally. Calling flush afterwards
could cause errors. It's also not really necessary. OutputStream.flush does
not guarantee persistence according to its JavaDoc. In contrast, calling
close does guarantee it.

What is the purpose of the change

Some FileSystem implementations fail when calling flush on a closed OutputStream (e.g. HDFS).
To cover this behavior in the tests, we added this check to the LocalDataOutputStream.

Brief change log

  • Removes the flush call: The data is persisted as part of the OutputStream.close call as stated in the JavaDoc
  • Added asserts to LocalDataOutputStream to cover this behavior in tests.

Verifying this change

  • Adds unit tests to LocalFileSystemTest to check for the assertions
  • Run CI to see whether other test failures pop up

Does this pull request potentially affect one of the following parts:

  • Dependencies (does it add or upgrade a dependency): no
  • The public API, i.e., is any changed class annotated with @Public(Evolving): no
  • The serializers: no
  • The runtime per-record code paths (performance sensitive): no
  • Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
  • The S3 file system connector: no

Documentation

  • Does this pull request introduce a new feature? no
  • If yes, how is the feature documented? not applicable

@XComp XComp changed the title [FLINK-26957][runtime] Removes flush in FileSystemJobResultStore [FLINK-26957][runtime] Removes flush in FileSystemJobResultStore.createDirtyResultInternal Mar 31, 2022
@flinkbot
Copy link
Collaborator

flinkbot commented Mar 31, 2022

CI report:

Bot commands The @flinkbot bot supports the following commands:
  • @flinkbot run azure re-run the last Azure build

@XComp XComp force-pushed the FLINK-26957 branch 2 times, most recently from 144146f to df4a61b Compare April 1, 2022 08:23
@XComp
Copy link
Contributor Author

XComp commented Apr 1, 2022

@flinkbot run azure

@XComp
Copy link
Contributor Author

XComp commented Apr 1, 2022

I forgot to change the unit tests expected error from IllegalStateException to IOException which caused a failure. -.- ...that's why the force-push

@XComp
Copy link
Contributor Author

XComp commented Apr 1, 2022

I added a test case for closing the OutputStream twice in the most-recent force-push.

@dmvk dmvk self-requested a review April 1, 2022 12:23
Copy link
Member

@dmvk dmvk left a comment

Choose a reason for hiding this comment

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

Hi @XComp, this already looks really good. Great job! <3 I've added few comments and questions, please take a look.

@XComp
Copy link
Contributor Author

XComp commented Apr 3, 2022

CI looks good - I created a 1.15 backport already to make CI pass (hoping that there are no additional changes required)

Copy link
Member

@dmvk dmvk left a comment

Choose a reason for hiding this comment

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

LGTM, great job! 👍 Can you please fix the commit history before merging?

XComp added 2 commits April 4, 2022 14:29
The writeValue calls close by default internally. Calling flush afterwards
could cause errors. It's also not really necessary. OutputStream.flush does
not guarantee persistence according to its JavaDoc. In contrast, calling
close does guarantee it.
…ify that no operation is allowed on a closed stream
@XComp
Copy link
Contributor Author

XComp commented Apr 4, 2022

I'm gonna merge. I only dropped on commit.

@XComp XComp merged commit caa296b into apache:master Apr 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants