PARQUET-2060: Fix infinite loop while reading corrupt files

[rathinb-db]

When a parquet file is corrupted, decompress can return 0 bytes. This can cause an infinite loop in the JDK readFully that calls the NonBlockedDecompressorStream read. Input streams are never supposed to return 0, but we do if there's a corrupt file.

By throwing an error, we break early and exit fast.

Make sure you have checked all steps below.

Jira

• My PR addresses the following Parquet Jira issues and references
  them in the PR title. For example, "PARQUET-1234: My Parquet PR"
  • https://issues.apache.org/jira/browse/PARQUET-2060
  • In case you are adding a dependency, check if the license complies with
    the ASF 3rd Party License Policy.

Tests

Add existing unit test. Manually tested with a corrupt file.

Commits

• My commits all reference Jira issues in their subject lines. In addition, my commits follow the guidelines
  from "How to write a good git commit message":
  1. Subject is separated from body by a blank line
  2. Subject is limited to 50 characters (not including Jira issue reference)
  3. Subject does not end with a period
  4. Subject uses the imperative mood ("add", not "adding")
  5. Body wraps at 72 characters
  6. Body explains "what" and "why", not "how"

Style

• My contribution adheres to the code style guidelines and Spotless passes.
  • To apply the necessary changes, run mvn spotless:apply -Pvector-plugins

Documentation

• In case of new functionality, my PR adds documentation that describes how to use it.
  • All the public functions and the classes in the PR contain Javadoc that explain what it does

[ConeyLiu]

Could you add a UT for this?

[rathinb-db]

Could you add a UT for this?

cc: @ConeyLiu
I've added a unit test. Please take a look and suggest any changes if any. I've added the try .. catch to make the exception handling more explicit.

[wgtmac]

Thanks for the fix! Could you please make the CI happy?

[wgtmac]

Rest LGTM

[rathinb-db]

Thanks for the inputs! I'd like to replace the mock with an actual corrupt file that can reliably reproduce this. Are there any simple ways to read the file and call NonBlockedDecompressorStream? cc: @wgtmac

[wgtmac]

Rest LGTM. Thanks! @rathinb-db

[wgtmac]

+1

@ConeyLiu Do you want to take another pass?

[ConeyLiu]

+1