av9ash/GitBugs huggingface dataset:
Bug: Add option and make 400 bad request retryable
Status: Open | Priority: Major | Resolution: 
Created: 21/Jun/22 18:40
Affects Version/s: 3.3.4

When one is using a customized credential provider via fs.s3a.aws.credentials.provider, e.g. org.apache.hadoop.fs.s3a.TemporaryAWSCredentialsProvider, when the provided credential by this pluggable provider is expired and return an error code of 400 as bad request exception.

Here, the current S3ARetryPolicy will fail immediately and does not retry on the S3A level. 

Our recent use case in HBase found this use case could lead to a Region Server got immediate abandoned from this Exception without retry, when the file system is trying open or S3AInputStream is trying to reopen the file. especially the S3AInputStream use cases, we cannot find a good way to retry outside of the file system semantic (because if a ongoing stream is failing currently it's considered as irreparable state), and thus we come up with this optional flag for retrying in S3A.


{code}
Caused by: com.amazonaws.services.s3.model.AmazonS3Exception: The provided token has expired. (Service: Amazon S3; Status Code: 400; Error Code: ExpiredToken; Request ID: XYZ; S3 Extended Request ID: ABC; Proxy: null), S3 Extended Request ID: 123
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleErrorResponse(AmazonHttpClient.java:1862)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleServiceErrorResponse(AmazonHttpClient.java:1415)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeOneRequest(AmazonHttpClient.java:1384)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:1154)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:811)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:779)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:753)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$500(AmazonHttpClient.java:713)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:695)
	at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:559)
	at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:539)
	at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:5453)
	at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:5400)
	at com.amazonaws.services.s3.AmazonS3Client.getObject(AmazonS3Client.java:1524)
	at org.apache.hadoop.fs.s3a.S3AFileSystem$InputStreamCallbacksImpl.getObject(S3AFileSystem.java:1506)
	at org.apache.hadoop.fs.s3a.S3AInputStream.lambda$reopen$0(S3AInputStream.java:217)
	at org.apache.hadoop.fs.s3a.Invoker.once(Invoker.java:117)
	... 35 more
{code}
Bug: Upgrade bundled Tomcat to 8.5.76 or higher
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 21/Jun/22 10:36
Affects Version/s: 2.10.1

Currently we are using 8.5.75 which is affected by {color:#222233}CVE-2022-25762{color}

More Details - [https://lists.apache.org/thread/qzkqh2819x6zsmj7vwdf14ng2fdgckw7]

Lets upgrade  8.5.76 or higher
Bug: Release Hadoop 3.3.4 critical fix update
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 16/Jun/22 09:45

Create a new release off the branch-3.3.3 line with a few more changes

* wrap up of security changes
* cut hadoop-cos out of hadoop-cloud-storage as its dependencies break s3a client...reinstate once the updated jar is tested
* try to get an arm build out tool
Bug: Provide a shim library for modern FS APIs
Status: Open | Priority: Major | Resolution: 
Created: 10/Jun/22 16:48
Affects Version/s: 3.3.0

Add a shim library to give libraries and applications built against hadoop 3.2 access to APIs and features in later versions, especially those delivering higher performance in cloud deployments. This will give them the ability to invoke those APIs when available, so gain from the work everyone has done. Key APIs are:

* openFile
* ByteBufferPositionedReadable
* Vectored IO

The library will either downgrade gracefully to existing code (openFile) or simply thrown UnsupportedException when invoked -but offer probes for every operation before invocation.

This module will compile against hadoop 3.2.0; it will be tested against that and later releases.

We can and should release this on a different schedule; though ideally we should issue releases in sync with new hadoop releases adding new supported API calls.

For that reason I think we could consider having separate git repository for it. Verifying that the shim works against hadoop PRs could actually become one of our regression tests -indeed, it should become one.
Bug: S3A audit log referrer header path contains '&'
Status: Open | Priority: Major | Resolution: 
Created: 25/May/22 09:46

{code:java}
"https://audit.example.org/hadoop/1/op_mkdirs/028e8604-c244-44be-9c5f-dd070c3000d6-00000180/?op=op_mkdirs&p1=Users/stevel/Projects/hadoop-trunk/hadoop-tools/hadoop-aws/target/test-dir/6/testContextURI/test/hadoop/&*%23$%23$@234&pr=stevel&ps=b73b8f7d-9a44-4259-94c2-da1dd28a7706&id=028e8604-c244-44be-9c5f-dd070c3000d6-00000180&t0=1&fs=028e8604-c244-44be-9c5f-dd070c3000d6&t1=1&ts=1645621486477" {code}
here 'p1' shouldn't contain '&', but in some cases it doesn't escape in the referrer header
Bug: Fix reentrancy check in SFTPFileSystem.close()
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 17/May/22 04:10
Affects Version/s: 3.3.1

{code:java}
@Override
public void close() throws IOException {
  if (closed.getAndSet(true)) {
    return;
  }
  try {
    super.close();
  } finally {
    if (connectionPool != null) {
      connectionPool.shutdown();
    }
  }
}
{code}
if you execute this method, the fs can not execute the deleteOnExit method because the fs is closed.

如果手动调用，sftp fs执行close方法关闭连接池，让jvm能正常退出，deleteOnExsist 将因为fs已关闭无法执行成功。如果不关闭，则连接池不会释放，jvm不能退出。

https://issues.apache.org/jira/browse/HADOOP-17528，这是3.2.0 sftpfilesystem的问题

 

Translated:
{quote}If it is called manually, sftp fs executes the close method to close the connection pool, so that the jvm can exit normally, deleteOnExist will fail to execute successfully because fs is closed. If it is not closed, the connection pool will not be released and the jvm cannot exit.
{quote}
Bug: Fix Hadoop-Common JavaDoc Error on branch-3.3
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 18/May/22 12:17
Affects Version/s: 3.3.0

Fix Hadoop-Common JavaDoc Error on branch-3.3.

In the PR([#4267|https://github.com/apache/hadoop/pull/4267]) of HADOOP-18224. Upgrade maven compiler plugin to 3.10.1, I found that hadoop-common has a lot of javadoc compilation errors. I fixed it on the trunk, hoping to backport these changes to branch 3.3. These changes will ensure that hadoop common moudle javadoc will pass in JDK11 compilation.
Bug: hadoop-client-runtime latest version 3.3.2 has security issues
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 19/Apr/22 23:19
Affects Version/s: 3.3.2

Currently in highest version of hadoop-client-runtime 3.3.2, there are following security vulnerabilities comes from dependencies:

com.fasterxml.jackson.core_jackson-databind in version 2.13.0, per [CVE-2020-36518|[https://nvd.nist.gov/vuln/detail/CVE-2020-36518],] need to be upgraded to 2.13.2.2.



commons-codec_commons-codec in version 1.11 per CODEC-134, need to be upgraded to 1.13 or higher

Thanks.
Bug: make jackson v1 a runtime scope dependency
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 07/Apr/22 14:12

In trunk, jackson v1 is only needed as a transitive dependency of jersey-json (1.19).

The jackson v1 jars still appear in hadoop pom so it would be useful to make them 'runtime' scope so that no hadoop code can compile with links to this old code.

 

[https://repository.apache.org/content/repositories/snapshots/org/apache/hadoop/hadoop-project/3.4.0-SNAPSHOT/hadoop-project-3.4.0-20220407.091529-1274.pom]

 

the linked PR is not needed if [https://github.com/apache/hadoop/pull/3988] is merged
Bug: create release docker builds failing with network issues retrieving artifacts
Status: Open | Priority: Major | Resolution: 
Created: 21/Apr/22 09:19
Affects Version/s: 3.3.3

the docker runs fail regularly when trying to retrieve artifacts off maven central due to (transient?) network errors


Two examples. 

{code}
[ERROR] Failed to execute goal on project hadoop-hdfs-httpfs: Could not resolve dependencies for project org.apache.hadoop:hadoop-hdfs-httpfs:jar:3.3.3-SNAPSHOT: Failed to collect dependencies at com.googlecode.json-simple:json-simple:jar:1.1.1: Failed to read artifact descriptor for com.googlecode.json-simple:json-simple:jar:1.1.1: Could not transfer artifact com.googlecode.json-simple:json-simple:pom:1.1.1 from/to maven-central (https://repo1.maven.org/maven2): Connection reset -> [Help 1]
{code}

{code}
[ERROR] Failed to execute goal on project hadoop-common: Could not resolve dependencies for project org.apache.hadoop:hadoop-common:jar:3.3.3-SNAPSHOT: The following artifacts could not be resolved: org.assertj:assertj-core:jar:3.12.2, org.apache.ant:ant:jar:1.10.11, com.google.protobuf:protobuf-java:jar:2.5.0, com.jcraft:jsch:jar:0.1.55, org.apache.curator:curator-recipes:jar:4.2.0, org.apache.sshd:sshd-core:jar:1.6.0, org.apache.ftpserver:ftpserver-core:jar:1.0.0, org.apache.ftpserver:ftplet-api:jar:1.0.0, org.apache.zookeeper:zookeeper:jar:tests:3.5.6, org.apache.commons:commons-compress:jar:1.21, org.codehaus.woodstox:stax2-api:jar:4.2.1, com.fasterxml.woodstox:woodstox-core:jar:5.3.0, com.squareup.okhttp3:mockwebserver:jar:3.7.0, com.squareup.okhttp3:okhttp:jar:3.7.0, com.squareup.okio:okio:jar:1.12.0, dnsjava:dnsjava:jar:2.1.7, org.xerial.snappy:snappy-java:jar:1.1.8.2, org.lz4:lz4-java:jar:1.7.1: Could not transfer artifact org.assertj:assertj-core:jar:3.12.2 from/to maven-central (https://repo1.maven.org/maven2): GET request of: org/assertj/assertj-core/3.12.2/assertj-core-3.12.2.jar from maven-central failed: Premature end of Content-Length delimited message body (expected: 4382102; received:
{code}
Bug: Remove base and bucket overrides for endpoint in ITestS3ARequesterPays.java
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 13/Apr/22 13:42
Affects Version/s: 3.3.3

If a user has set the endpoint for their bucket in a test environment, we should ignore that in a test that won't use the bucket that the endpoint is set for. In this case, we are using "s3a://usgs-landsat/" which is in the region us-west-2, and would fail if the user has explicitly set the endpoint to something else.

Example (I have set the endpoint to ap-south-1):
{code:java}
[ERROR] testRequesterPaysDisabledFails(org.apache.hadoop.fs.s3a.ITestS3ARequesterPays)  Time elapsed: 9.323 s  <<< ERROR!
org.apache.hadoop.fs.s3a.AWSRedirectException: getFileStatus on s3a://usgs-landsat/collection02/catalog.json: com.amazonaws.services.s3.model.AmazonS3Exception: The bucket is in this region: us-west-2. Please use this region to retry the request (Service: Amazon S3; Status Code: 301; Error Code: 301 Moved Permanently; Request ID: Z09V8PMEEN5PHDRZ; S3 Extended Request ID: B7KDQntCuVmLJAyXvuY4UNXjdUrgn3xd26n8u7ThueNNxvKas6g3RsXo7oxBcvHrpcous2L+Lbk=; Proxy: null), S3 Extended Request ID: B7KDQntCuVmLJAyXvuY4UNXjdUrgn3xd26n8u7ThueNNxvKas6g3RsXo7oxBcvHrpcous2L+Lbk=:301 Moved Permanently: The bucket is in this region: us-west-2. Please use this region to retry the request (Service: Amazon S3; Status Code: 301; Error Code: 301 Moved Permanently; Request ID: Z09V8PMEEN5PHDRZ; S3 Extended Request ID: B7KDQntCuVmLJAyXvuY4UNXjdUrgn3xd26n8u7ThueNNxvKas6g3RsXo7oxBcvHrpcous2L+Lbk=; Proxy: null)
 at org.apache.hadoop.fs.s3a.S3AUtils.translateException(S3AUtils.java:233)
 at org.apache.hadoop.fs.s3a.S3AUtils.translateException(S3AUtils.java:171)
 at org.apache.hadoop.fs.s3a.S3AFileSystem.s3GetFileStatus(S3AFileSystem.java:3440)
 at org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:3346)
 at org.apache.hadoop.fs.s3a.S3AFileSystem.extractOrFetchSimpleFileStatus(S3AFileSystem.java:4890)
 at org.apache.hadoop.fs.s3a.S3AFileSystem.lambda$executeOpen$6(S3AFileSystem.java:1437)
 at org.apache.hadoop.fs.statistics.impl.IOStatisticsBinding.invokeTrackingDuration(IOStatisticsBinding.java:543)
 at org.apache.hadoop.fs.statistics.impl.IOStatisticsBinding.lambda$trackDurationOfOperation$5(IOStatisticsBinding.java:524)
 at org.apache.hadoop.fs.statistics.impl.IOStatisticsBinding.trackDuration(IOStatisticsBinding.java:445)
 at org.apache.hadoop.fs.s3a.S3AFileSystem.executeOpen(S3AFileSystem.java:1435)
 at org.apache.hadoop.fs.s3a.S3AFileSystem.open(S3AFileSystem.java:1409)
  
<......>{code}
CC: [~stevel@apache.org]  [~mthakur]  [~dannycjones]
Bug: Fix ZStandardCompressor bytesRead meta when using BlockCompressorStream
Status: Resolved | Priority: Major | Resolution: Not A Bug
Created: 12/Apr/22 08:11
Affects Version/s: 3.3.1

{{There is a bug when we use ZStandardCompressor which wrapped by `BlockCompressorStream`. }}

The reason is the  `bytesRead` in ZStandardCompressor implement is always zero, which should be set to bytes length when call setInput.

!image-2022-04-12-16-14-37-105.png!

Thus I makes the `rawWriteInt` always write zero

!image-2022-04-12-16-11-10-443.png!
Bug: Fix multiple_bindings warning about slf4j-reload4j
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 04/Apr/22 12:54

Jar of slf4j-relad4j exists in libdirs of both common and hdfs.
{noformat}
$ ~/dist/hadoop-3.2.4-SNAPSHOT/bin/hdfs dfs -ls /
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/ext/dist/hadoop-3.2.4-SNAPSHOT/share/hadoop/common/lib/slf4j-reload4j-1.7.35.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/ext/dist/hadoop-3.2.4-SNAPSHOT/share/hadoop/hdfs/lib/slf4j-reload4j-1.7.35.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Reload4jLoggerFactory]


$ find ~/dist/hadoop-3.2.4-SNAPSHOT/ -name 'slf4j-reload4j-*.jar'
/home/centos/dist/hadoop-3.2.4-SNAPSHOT/share/hadoop/common/lib/slf4j-reload4j-1.7.35.jar
/home/centos/dist/hadoop-3.2.4-SNAPSHOT/share/hadoop/hdfs/lib/slf4j-reload4j-1.7.35.jar
{noformat}
Bug: Public dataset class for S3A integration tests
Status: Open | Priority: Minor | Resolution: 
Created: 06/Apr/22 10:16

Introduction of PublicDatasetTestUtils as proposed previously in some of the ideas for refactoring S3A incrementally. Some of its responsibilities:

- Source of truth for getting URI based on public data set.
- Maybe keep the methods specific to their purpose where possible? We might need {{s3a://landsat-pds/scene_list.gz}} specifically for some tests, but other tests may just need a bucket with a bunch of keys.
- Introduce test assumptions about the S3 endpoint or AWS partition. If we’re not looking at 'aws' partition, skip test.

How might we make this generic for non-{{aws}} partition S3 or S3API-compatible object stores?

- Ideally allow for future extension to provide some easy ways to override the bucket if tester has an alternative source? I see "fs.s3a.scale.test.csvfile" already has a little bit of this.
- We could have something which takes a path to a hadoop XML config file; we'd have a default resource but the maven build could be pointed at another via a command line property. this file could contain all the settings for a test against a partition or internal s3-compatible store
Bug: Memory fragmentation in ChecksumFileSystem Vectored IO implementation.
Status: Resolved | Priority: Minor | Resolution: Won't Fix
Created: 16/Jun/22 21:07
Affects Version/s: 3.4.0

As we have implemented merging of ranges in the ChecksumFSInputChecker implementation of vectored IO api, it can lead to memory fragmentation. Let me explain by example.

 

Suppose client requests for 3 ranges. 

0-500, 700-1000 and 1200-1500.

Now because of merging, all the above ranges will get merged into one and we will allocate a big byte buffer of 0-1500 size but return sliced byte buffers for the desired ranges.

Now once the client is done reading all the ranges, it will only be able to free the memory for requested ranges and memory of the gaps will never be released for eg here (500-700 and 1000-1200).

 

Note this only happens for direct byte buffers.
Bug: Log retry count while handling exceptions in RetryInvocationHandler
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 04/Apr/22 11:19
Affects Version/s: 2.10.2

As part of failure handling in RetryInvocationHandler, we log details of the Exception details with which API was invoked, failover attempts, delay.

For the purpose of better debugging as well as fine-tuning of retry params, it would be good to also log retry count that we already maintain in the Counter object.
Bug: Enhance WritableName to be able to return aliases for classes that use serializers
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 21/Apr/22 20:50
Affects Version/s: 3.3.6

WritableName allows users shim in aliases for writables, in the case where a SequenceFile was written with a Writable class that has since been renamed or moved to another package. However, this requires that the aliased class extend Writable. 

Separately it's possible to configure jobs with keys and values which don't actually extend Writable. Instead they are meant to be serialized/deserialized using the serialization classes defined in {{io.serializations}} config.

Unfortunately, the current implementation does not support these key/value classes. All we need to do to support this is remove the {{.asSubclass(Writable.class)}} as is already the case for the default.
Bug: Document "io.file.buffer.size" must be greater than zero
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 22/Apr/22 10:39
Affects Version/s: 3.4.0

when the configuration file in the "io.file.buffer.size" field is set to a value less than or equal to zero, hdfs can start normally, but read and write data will have problems.


When the value is less than zero, the shell will throw the following exception:
{code:java}
hadoop@ljq1:~/hadoop-3.1.3-work/bin$ ./hdfs dfs -cat mapred
-cat: Fatal internal error
java.lang.NegativeArraySizeException: -4096
        at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:93)
        at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:68)
        at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:129)
        at org.apache.hadoop.fs.shell.Display$Cat.printToStdout(Display.java:101)
        at org.apache.hadoop.fs.shell.Display$Cat.processPath(Display.java:96)
        at org.apache.hadoop.fs.shell.Command.processPaths(Command.java:331)
        at org.apache.hadoop.fs.shell.Command.processPathArgument(Command.java:303)
        at org.apache.hadoop.fs.shell.Command.processArgument(Command.java:285)
        at org.apache.hadoop.fs.shell.Command.processArguments(Command.java:269)
        at org.apache.hadoop.fs.shell.FsCommand.processRawArguments(FsCommand.java:120)
        at org.apache.hadoop.fs.shell.Command.run(Command.java:176)
        at org.apache.hadoop.fs.FsShell.run(FsShell.java:328)
        at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)
        at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:90)
        at org.apache.hadoop.fs.FsShell.main(FsShell.java:391){code}
When the value is equal to zero, the shell command will always block
{code:java}
hadoop@ljq1:~/hadoop-3.1.3-work/bin$ ./hdfs dfs -cat mapred
^Z
[2]+  Stopped                 ./hdfs dfs -cat mapred{code}
The description of the configuration file is not clear enough, it may make people think that set to 0 to enter the non-blocking mode.
 
{code:java}
<property>   
    <name>io.file.buffer.size</name>   
    <value>4096</value>   
    <description>The size of buffer for use in sequence files.   
    The size of this buffer should probably be a multiple of hardware   
    page size (4096 on Intel x86), and it determines how much data is   
    buffered during read and write operations.</description> 
</property>{code}
 
Considering that this value is uesd by hdfs and mapreduce frequently, we should make this value must be a number greater than zero.
Bug: tests in ITestS3AInputStreamPerformance are failing 
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 10/May/22 12:04
Affects Version/s: 3.4.0

The following tests are failing when prefetching is enabled:

testRandomIORandomPolicy - expects stream to be opened 4 times (once for every random read), but prefetching will only open twice. 

testDecompressionSequential128K - expects stream to be opened once, but prefetching will open once for each block the file has. landsat file used in the test has size 42MB, prefetching block size = 8MB, expected open count is 6.

 testReadWithNormalPolicy - same as above. 

testRandomIONormalPolicy - executes random IO, but with a normal policy. S3AInputStream will abort the stream and change the policy, prefetching handles random IO by caching blocks so doesn't do any of that. 

testRandomReadOverBuffer - multiple assertions failing here, also depends a lot on readAhead values, not very relevant for prefetching
Bug: Remove lower limit on s3a prefetching/caching block size
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 19/May/22 15:46
Affects Version/s: 3.4.0

The minimum allowed block size currently is {{PREFETCH_BLOCK_DEFAULT_SIZE}} (8MB).
{code:java}
this.prefetchBlockSize = intOption(
                    conf, PREFETCH_BLOCK_SIZE_KEY, PREFETCH_BLOCK_DEFAULT_SIZE, PREFETCH_BLOCK_DEFAULT_SIZE);{code}
[https://github.com/apache/hadoop/blob/3aa03e0eb95bbcb066144706e06509f0e0549196/hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/S3AFileSystem.java#L487-L488]

Why is this the case and should we lower or remove it?
Bug: Fix failure of extracting JIRA id from commit message in git_jira_fix_version_check.py
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 23/May/22 09:00
Affects Version/s: 2.10.3

git_jira_fix_version_check.py is confused by commit message like {{"YARN-1151. Ability to configure auxiliary services from HDFS-based JAR files."}} which contains both {{YARN-}} and {{{}HDFS-{}}}. The latter {{HDFS-}} is unexpectedly picked as JIRA issue id then 404 is thrown on accessing invalid URL like "https://issues.apache.org/jira/rest/api/2/issue/HDFS-".
Bug: Remove Unnecessary semicolon ';' 
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 09/Jun/22 23:42
Affects Version/s: 3.4.0

while reading the code, I found a very tiny optimization point, part of the code contains 2 semicolons at the end, I will fix it. Because this change is simple, I fixed it in One JIRA.

{code:java}
private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();;
{code}
Bug: Upgrade dependency-check-maven to 7.1.1
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 17/Jun/22 01:30
Affects Version/s: 3.3.3

The OWASP dependency-check-maven Plugin version has corrected various false positives in 7.1.1. We can upgrade to it.

https://github.com/jeremylong/DependencyCheck/milestone/45?closed=1
Bug: Improve S3A delegations token documentation
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 30/Jun/22 12:48
Affects Version/s: 3.4.0

The current [delegations token documentation|https://github.com/apache/hadoop/blob/trunk/hadoop-tools/hadoop-aws/src/site/markdown/tools/hadoop-aws/delegation_tokens.md] has some typos, this task tracks fixing those.
Bug: Update google-gson to 2.9.0
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 17/Jun/22 23:07
Affects Version/s: 3.3.5

Update to the Gson 2.9.0 that has many [fixes|https://github.com/google/gson/releases/tag/gson-parent-2.9.0], and backward-compatible as long as Java 7+ is used.

Fixes CVE-2022-25647; Dos when unmarshalling data