av9ash/GitBugs huggingface dataset:
Bug: Upgrade protobuf to 3.15.0 or newer
Status: Open | Priority: Major | Resolution: 
Created: 11/Aug/23 17:11
Affects Version/s: 3.3.5

Hadoop includes a shaded version of protobuf-java (currently uses protobuf-java 3.7.1), however, [CVE-2021-22570|https://nvd.nist.gov/vuln/detail/CVE-2021-22570] is a HIGH vulnerability that can be fixed by upgrading to protobuf-java 3.15.0.

Please consider upgrading hadoop-shaded-protobuf to this newer version.

 

Relates to HADOOP-13363 and HADOOP-16821
Bug: Rebuild Exceptions on Client side to get genuine exceptions
Status: Open | Priority: Major | Resolution: 
Created: 20/Jul/23 09:03

In current's RPC design, if Server sends an exception back, Client can only rebuild the exception according to the original exception's error message, if the exceptions has some fields containing important information, they will be discarded since we can not rebuild them based on message string easily.

This ticket is to introduce a new interface for Exceptions which supports reconstructing. If Clients want to rebuild the exception, they can just implement the methods and the reconstruction will be done automatically.

The interface uses String[] as parameter for simplicity.  I thought of using Protobuf to store all the exceptions or fields, but the generacity can not be perfectlly met. So we need Client to support it by accepting "String[]" and transform the String to it's original type.
Bug: Upgrade version of aws-java-sdk-bundle to 1.12.368 avoid verify error. 
Status: Resolved | Priority: Major | Resolution: Cannot Reproduce
Created: 20/Jul/23 13:00
Affects Version/s: 3.3.6

The compilation failed when I packaged through the maven command 

 
{code:java}
mvn clean install -DskipTests -Dtar -Pdist -Pnative  {code}
 

 

report an error: 

 
{code:java}
[WARNING]
Dependency convergence error for com.amazonaws:aws-java-sdk-simpleworkflow:1.12.367 paths to dependency are:
+-org.apache.hadoop:hadoop-aws:3.3.6
  +-com.amazonaws:aws-java-sdk-bundle:1.12.367
    +-com.amazonaws:aws-java-sdk:1.12.367
      +-com.amazonaws:aws-java-sdk-simpleworkflow:1.12.367
and
+-org.apache.hadoop:hadoop-aws:3.3.6
  +-com.amazonaws:aws-java-sdk-bundle:1.12.367
    +-com.amazonaws:aws-java-sdk:1.12.367
      +-com.amazonaws:aws-java-sdk-swf-libraries:1.11.22
        +-com.amazonaws:aws-java-sdk-simpleworkflow:1.11.22
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:
Failed while enforcing releasability. See above detailed error message. {code}
 
com.amazonaws:aws-java-sdk-swf-libraries are not required
Bug: s3a large file prefetch tests are too slow, don't validate data
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 14/Jul/23 17:47
Affects Version/s: 3.3.9

the large file prefetch tests (including LRU cache eviction) are really slow.

moving under -scale may hide the problem for most runs, but they are still too slow, can time out, etc etc.


also, and this is very, very important, they can't validate the data.

Better: 
* test on smaller files by setting a very small block size (1k bytes or less) just to force paged reads of a small 16k file.
* with known contents to the values of all forms of read can be validated
* maybe the LRU tests can work with a fake remote object which can then be used in a unit test
* extend one of the huge file tests to read from there -including s3-CSE encryption coverage.
Bug: s3a prefetch read/write file operations should guard channel close
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 18/Jul/23 02:11
Affects Version/s: 3.3.9

As per Steve's suggestion from s3a prefetch LRU cache,

s3a prefetch disk based cache file read and write operations should guard against close of FileChannel and WritableByteChannel, close them even if read/write operations throw IOException.
Bug: S3A prefetching: switch to prefetching for chosen read policies
Status: Open | Priority: Major | Resolution: 
Created: 05/Jul/23 13:23
Affects Version/s: 3.3.6

before switching to prefetching input stream everywhere, add an option to list which of the fs.option.openfile.read.policy policies to switch too, e.g
 
fs.s3a.inputstream.prefetch.policies=whole-file, sequential, adaptive

this would leave random and vectored on s3a input stream.
Bug: s3a prefetching to use split start/end options to limit prefetch range
Status: In Progress | Priority: Major | Resolution: 
Created: 05/Jul/23 13:26

the bundled hadoop record readers pass the split start/end down to openFile() -these can be used by the prefetching stream as hints as to where to start and stop prefetching.

Hints only as
* records can extend past split end; that last record will still be read when split end < EOF
* for formats with footers which get read, caching that footer is important
Bug: hadoop distcp -delete sends deleted data to null instead of trash
Status: Open | Priority: Major | Resolution: 
Created: 11/Jul/23 16:45

In the docs the -delete option is specified as moving data to Trash when it is enabled:

[https://hadoop.apache.org/docs/current/hadoop-distcp/DistCp.html#:~:text=%2Ddelete,or%20overwrite%20options].

However, it does not go to trash, it goes to null. I know of two instances where this misunderstanding has caused data loss.

The statement that the data goes to Trash should be removed, and it should be specified that the data is deleted.

An earlier reproduction:

hdfs dfs -mkdir -p /tmp/test1/test2

hdfs dfs -put /tmp/test.img /tmp/

hdfs dfs -put /tmp/test.img /tmp/test2/file1

 

drwxr-xr-x   - root   supergroup          0 2023-04-17 19:07 /tmp/test1

drwxr-xr-x   - hdfs   supergroup          0 2023-04-17 19:06 /tmp/test1/test2

{-}rw-r{-}{-}r{-}-   3 hdfs   supergroup 1073741824 2023-04-17 19:06 /tmp/test1/test2/file1

 

distcp -update -delete /tmp/test.img /tmp/test1

 

{-}rw-r{-}{-}r{-}-   3 root   supergroup 1073741824 2023-04-17 18:52 /tmp/test.img

drwxr-xr-x   - root   supergroup          0 2023-04-17 19:03 /tmp/test1

{-}rw-r{-}{-}r{-}-   3 hdfs   supergroup 1073741824 2023-04-17 19:03 /tmp/test1/test.img

 

2023-04-17 19:08:44,252 INFO FSNamesystem.audit: allowed=true   ugi=hdfs (auth:SIMPLE)  ip=/172.25.41.195       cmd=delete      src=/tmp/test1/test2    dst=null        perm=null       proto

 

[hdfs@c4401-node2 root]$ date

Mon Apr 17 19:11:22 UTC 2023
Bug: remove head bucket request from calls which can be made without audit header
Status: Open | Priority: Minor | Resolution: 
Created: 15/Aug/23 14:57
Affects Version/s: 3.4.0

once getBucketLocation is done in s3a client, not v1 sdk, the requests MUST have an audit header. Therefore bucket head requests can be removed from the list of "requests which we allow without a header"

also, why isn't the call to getBucketEncryption in ITestS3AConfiguration failing/being picked up as a failure?
Bug: s3a client SSLException is raised after very long timeout "Unsupported or unrecognized SSL message"
Status: Open | Priority: Minor | Resolution: 
Created: 03/Aug/23 12:44
Affects Version/s: 3.3.4

I've tried to connect from PySpark to Minio running in docker.

Installing PySpark and starting Minio:
{code:bash}
pip install pyspark==3.4.1

docker run --rm -d --hostname minio --name minio -p 9000:9000 -p 9001:9001 -e MINIO_ACCESS_KEY=access -e MINIO_SECRET_KEY=Eevoh2wo0ui6ech0wu8oy3feiR3eicha -e MINIO_ROOT_USER=admin -e MINIO_ROOT_PASSWORD=iepaegaigi3ofa9TaephieSo1iecaesh bitnami/minio:latest
docker exec minio mc mb test-bucket
{code}
Then create Spark session:
{code:python}
from pyspark.sql import SparkSession

spark = SparkSession.builder\
          .config("spark.jars.packages", "org.apache.hadoop:hadoop-aws:3.3.4")\
          .config("spark.hadoop.fs.s3a.endpoint", "localhost:9000")\
          .config("spark.hadoop.fs.s3a.connection.ssl.enabled", "true")\
          .config("spark.hadoop.fs.s3a.path.style.access", "true")\
          .config("spark.hadoop.fs.s3a.access.key", "access")\
          .config("spark.hadoop.fs.s3a.secret.key", "Eevoh2wo0ui6ech0wu8oy3feiR3eicha")\
          .config("spark.hadoop.fs.s3a.aws.credentials.provider", "org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider")\
          .getOrCreate()
spark.sparkContext.setLogLevel("debug")
{code}
And try to access some object in a bucket:
{code:python}
import time

begin = time.perf_counter()
spark.read.format("csv").load("s3a://test-bucket/fake")
end = time.perf_counter()

py4j.protocol.Py4JJavaError: An error occurred while calling o40.load.
: org.apache.hadoop.fs.s3a.AWSClientIOException: getFileStatus on s3a://test-bucket/fake: com.amazonaws.SdkClientException: Unable to execute HTTP request: Unsupported or unrecognized SSL message: Unable to execute HTTP request: Unsupported or unrecognized SSL message
...
{code}
[^ssl.log]
{code:python}
>>> print((end-begin)/60, "min")
14.72387898775002 min
{code}
I was waiting almost *15 minutes* to get the exception from Spark. The reason was I tried to connect to endpoint with {{fs.s3a.connection.ssl.enabled=true}}, but Minio is configured to listen for HTTP protocol only.

Is there any way to immediately raise exception if SSL connection cannot be established?


If I try to pass wrong endpoint, like {{localhos:9000}}, I'll get exception like this in just 5 seconds:
{code:java}
: org.apache.hadoop.fs.s3a.AWSClientIOException: getFileStatus on s3a://test-bucket/fake: com.amazonaws.SdkClientException: Unable to execute HTTP request: test-bucket.localhos: Unable to execute HTTP request: test-bucket.localhos
...
{code}
[^host.log]
{code:python}
>>> print(end-begin, "sec")
5.700424307000503 sec
{code}
I know about options like {{fs.s3a.attempts.maximum}} and {{{}fs.s3a.retry.limit{}}}, setting them to 1 will cause raising exception just immediately. But this does not look right.
Bug: Add enQueue time to RpcMetrics
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 05/Aug/23 06:32
Affects Version/s: 3.4.0

Sometimes, the request time observed by the client is much longer than the queue + process time on the RPC server. Perhaps the RPC request 'waiting enQueue' took too long on the RPC server, so we should add enQueue time to RpcMetrics.
Bug: Upgrade ZooKeeper to 3.6.4
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 25/Aug/23 14:20
Affects Version/s: 3.3.6

While ZooKeeper 3.6 is already EOL, we can upgrade to the final release of the ZooKeeper 3.6 as short-term fix until bumping to ZooKeeper 3.7 or later. Dependency convergence error must be addressed on {{-Dhbase.profile=2.0}}.

{noformat}
$ mvn clean install -Dzookeeper.version=3.6.4 -Dhbase.profile=2.0 -DskipTests clean install
Dependency convergence error for org.apache.yetus:audience-annotations:jar:0.13.0:compile paths to dependency are:
+-org.apache.hadoop:hadoop-yarn-server-timelineservice-hbase-common:jar:3.4.0-SNAPSHOT
  +-org.apache.hadoop:hadoop-common:test-jar:tests:3.4.0-SNAPSHOT:test
    +-org.apache.zookeeper:zookeeper:jar:3.6.4:compile
      +-org.apache.zookeeper:zookeeper-jute:jar:3.6.4:compile
        +-org.apache.yetus:audience-annotations:jar:0.13.0:compile
and
+-org.apache.hadoop:hadoop-yarn-server-timelineservice-hbase-common:jar:3.4.0-SNAPSHOT
  +-org.apache.hadoop:hadoop-common:test-jar:tests:3.4.0-SNAPSHOT:test
    +-org.apache.zookeeper:zookeeper:jar:3.6.4:compile
      +-org.apache.yetus:audience-annotations:jar:0.13.0:compile
and
+-org.apache.hadoop:hadoop-yarn-server-timelineservice-hbase-common:jar:3.4.0-SNAPSHOT
  +-org.apache.hbase:hbase-common:jar:2.2.4:compile
    +-org.apache.yetus:audience-annotations:jar:0.5.0:compile
{noformat}
Bug: s3a DelegationToken plugin to expand return type of deploy/binding
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 08/Jul/23 13:10
Affects Version/s: 3.4.0

Change the binding result of s3a DT services beyond just a credential list

this will the extension point
* return a new signer integrated with the fs
* add something to help with the building the requests to delete objects during paged delete
* gives us an option to add any more stuff

this is incompatible, but the move to AWS v2 breaks DTs bindings anyway...
Bug: S3ARetryPolicy to use sdk exception retryable() if it is valid
Status: Resolved | Priority: Minor | Resolution: Won't Fix
Created: 29/Aug/23 16:07
Affects Version/s: 3.4.0

S3ARetryPolicy to use sdk exception retryable() if it is appropriate

An initial {{RetryFromAWSClientIOException}} policy has been written, but not turned on as it there's too much risk of suddenly not retrying where we did today.
Bug: Refactor @Test(expected) with assertThrows
Status: Open | Priority: Minor | Resolution: 
Created: 25/Aug/23 13:41

I am working on research that investigates test smell refactoring in which we identify alternative implementations of test cases, study how commonly used these refactorings are, and assess how acceptable they are in practice.

The smell occurs when exception handling can alternatively be implemented using assertion rather than annotation: using {{assertThrows(Exception.class, () -> \{...});}} instead of {{{}@Test(expected = Exception.class){}}}.

While there are many cases like this, we aim in this pull request to get your feedback on this particular test smell and its refactoring. Thanks in advance for your input.
Bug: Spark insertInto with location GCS bucket root not supported
Status: Open | Priority: Minor | Resolution: 
Created: 20/Aug/23 06:55
Affects Version/s: 3.3.3

 
{noformat}
scala> import org.apache.hadoop.fs.Path
import org.apache.hadoop.fs.Path
scala> val path: Path = new Path("gs://test_dd123/")
path: org.apache.hadoop.fs.Path = gs://test_dd123/

scala> path.suffix("/num=123")
java.lang.NullPointerException
  at org.apache.hadoop.fs.Path.<init>(Path.java:150)
  at org.apache.hadoop.fs.Path.<init>(Path.java:129)
  at org.apache.hadoop.fs.Path.suffix(Path.java:450){noformat}
 

Path.suffix throws NPE when writing into GS buckets root. 

 

In our Organisation, we are using GCS bucket root location to point to our Hive table. Dataproc's latest 2.1 uses *Hadoop* *3.3.3* and this needs to be fixed in 3.3.3.

Spark Scala code to reproduce this issue
{noformat}
val DF = Seq(("test1", 123)).toDF("name", "num")
DF.write.option("path", "gs://test_dd123/").mode(SaveMode.Overwrite).partitionBy("num").format("orc").saveAsTable("schema_name.table_name")


val DF1 = Seq(("test2", 125)).toDF("name", "num")
DF1.write.mode(SaveMode.Overwrite).format("orc").insertInto("schema_name.table_name")


java.lang.NullPointerException
  at org.apache.hadoop.fs.Path.<init>(Path.java:141)
  at org.apache.hadoop.fs.Path.<init>(Path.java:120)
  at org.apache.hadoop.fs.Path.suffix(Path.java:441)
  at org.apache.spark.sql.execution.datasources.InsertIntoHadoopFsRelationCommand.$anonfun$getCustomPartitionLocations$1(InsertIntoHadoopFsRelationCommand.scala:254) {noformat}
Bug: Multiple token access is supported in HA noZK KMS environment
Status: Open | Priority: Minor | Resolution: 
Created: 24/Aug/23 12:23
Affects Version/s: 3.3.6

When there is no configuration of ZooKeeper synchronization for secrets on the KMS server (hadoop.kms.authentication.signer.secret.provider is null), the YARN MapReduce job fails to run successfully. The reason is that the KMS returns an error "invalidToken" as it cannot find the corresponding token in the cache.

!image-2023-08-24-19-53-24-665.png!

Is it possible to achieve fault tolerance by accessing multiple KMS services without configuring zookeeper for synchronization in KMS?
Bug: Address Netty 4.x / CWE-295 by configuring hostname verification
Status: Open | Priority: Minor | Resolution: 
Created: 25/Jul/23 18:18
Affects Version/s: 3.3.6

Our SAST tool has picked up that the version of Netty 4.x used by Hadoop is vulnerable to [Security Vulnerability - Common Weakness Enumeration (CWE) CWE-295 · Issue #9930 · netty/netty (github.com)|https://github.com/netty/netty/issues/9930]. Until Netty 5 is released (which will enable it by default), the remediation is to enable host name verification ([SslContext (Netty API Reference (4.1.95.Final))|https://netty.io/4.1/api/io/netty/handler/ssl/SslContext.html#newHandler-io.netty.buffer.ByteBufAllocator-java.util.concurrent.Executor-]).
Bug: TestRPCCallBenchmark timeout
Status: Open | Priority: Minor | Resolution: 
Created: 10/Aug/23 03:05

The UT TestRPCCallBenchmark failed in pr [5926|https://github.com/apache/hadoop/pull/5926], this issue will track it.

{code:java}
[ERROR] testBenchmarkWithProto(org.apache.hadoop.ipc.TestRPCCallBenchmark)  Time elapsed: 20.006 s  <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 20000 milliseconds
	at java.lang.Object.wait(Native Method)
	at java.lang.Thread.join(Thread.java:1257)
	at java.lang.Thread.join(Thread.java:1331)
	at org.apache.hadoop.test.MultithreadedTestUtil$TestContext.stop(MultithreadedTestUtil.java:164)
	at org.apache.hadoop.ipc.RPCCallBenchmark.run(RPCCallBenchmark.java:326)
	at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:82)
	at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:97)
	at org.apache.hadoop.ipc.TestRPCCallBenchmark.testBenchmarkWithProto(TestRPCCallBenchmark.java:30)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.lang.Thread.run(Thread.java:750)
{code}
Bug: Some fs.s3a.* config values are different in sources and documentation
Status: Open | Priority: Minor | Resolution: 
Created: 03/Aug/23 12:24
Affects Version/s: 3.3.6

For config option {{fs.s3a.retry.throttle.interval}} default value in source code is {{500ms}}:
{code:java}
public static final String RETRY_THROTTLE_INTERVAL_DEFAULT = "500ms";
{code}
https://github.com/apache/hadoop/blob/rel/release-3.3.6/hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/Constants.java#L921

In {{core-default.xml}} it has value {{100ms}}, but in the description {{500ms}}:
{code:xml}
<property>
  <name>fs.s3a.retry.throttle.interval</name>
  <value>100ms</value>
  <description>
    Initial between retry attempts on throttled requests, +/- 50%. chosen at random.
    i.e. for an intial value of 3000ms, the initial delay would be in the range 1500ms to 4500ms.
    Backoffs are exponential; again randomness is used to avoid the thundering heard problem.
    500ms is the default value used by the AWS S3 Retry policy.
  </description>
</property>
{code}
https://github.com/apache/hadoop/blob/rel/release-3.3.6/hadoop-common-project/hadoop-common/src/main/resources/core-default.xml#L1750
This change introduced in HADOOP-16823.

In Hadoop-AWS module documentation it has value {{1000ms}}:
{code:xml}
<property>
  <name>fs.s3a.retry.throttle.interval</name>
  <value>1000ms</value>
  <description>
    Interval between retry attempts on throttled requests.
  </description>
</property>
{code}
https://github.com/apache/hadoop/blob/rel/release-3.3.6/hadoop-tools/hadoop-aws/src/site/markdown/tools/hadoop-aws/index.md?plain=1#L1223
File was created in HADOOP-13786, and value is left unchanged since when.

In performance tuning page it has up-to-date value {{500ms}}:
{code:xml}
<property>
  <name>fs.s3a.retry.throttle.interval</name>
  <value>500ms</value>
  <description>
    Interval between retry attempts on throttled requests.
  </description>
</property>
{code}
https://github.com/apache/hadoop/blob/rel/release-3.3.6/hadoop-tools/hadoop-aws/src/site/markdown/tools/hadoop-aws/performance.md?plain=1#L435
This change introduced in HADOOP-15076.

The same issue with:
* {{fs.s3a.retry.throttle.limit}} - in source code it has value {{20}}, but in some documents still old value ${fs.s3a.attempts.maximum}
* {{fs.s3a.connection.establish.timeout}} - in source code it has value {{50_000}}, in config file & documentation {{5_000}}
* {{fs.s3a.attempts.maximum}} - in source code it has value {{10}}, in config file & documentation {{20}}
* {{fs.s3a.threads.max}} - in source & documentation code it has value {{10}}, in config file {{64}}
* {{fs.s3a.max.total.tasks}} - in source code & config it has value {{32}}, in documentation {{5}}
* {{fs.s3a.connection.maximum}} - in source code & config it has value {{96}}, in documentation {{15}} or {{30}}

Please sync these values, outdated documentation is very painful to work with.
As an idea, is it possible to use {{core-default.xml}} directly in documentation, or generate this documentation from docstrings in Java code?
Bug: S3A StagingCommitter does not clean up staging-uploads directory
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 06/Jul/23 10:39
Affects Version/s: 3.2.2

When setting up StagingCommitter and its internal FileOutputCommitter, a temporary directory that holds MPU information will be created on the default FS, which by default is to be /user/${USER}/tmp/staging/${USER}/${UUID}/staging-uploads.

On a successful job commit, its child directory (_temporary) will be [cleaned up|https://github.com/apache/hadoop/blob/a36d8adfd18e88f2752f4387ac4497aadd3a74e7/hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/commit/staging/StagingCommitter.java#L516] properly, but ${UUID}/staging-uploads will remain.

This will result in having too many empty ${UUID}/staging-uploads directories under /user/${USER}/tmp/staging/${USER}, and will eventually cause an issue in an environment where the max number of items in a directory is capped (e.g. by dfs.namenode.fs-limits.max-directory-items in HDFS).

{noformat}
The directory item limit of /user/${USER}/tmp/staging/${USER} is exceeded: limit=1048576 items=1048576
	at org.apache.hadoop.hdfs.server.namenode.FSDirectory.verifyMaxDirItems(FSDirectory.java:1205)
{noformat}
Bug: ITestS3APrefetchingCacheFiles teardown failure if setup() fails
Status: Open | Priority: Trivial | Resolution: 
Created: 18/Sep/23 12:24
Affects Version/s: 3.4.0


if the ITestS3APrefetchingCacheFiles setup fails before conf is set, teardown fails...need to wrap the cleanup code with a check for conf!=null

{code}
[ERROR] testCacheFileExistence(org.apache.hadoop.fs.s3a.ITestS3APrefetchingCacheFiles)  Time elapsed: 0.156 s  <<< ERROR!
java.lang.NullPointerException
        at org.apache.hadoop.fs.s3a.ITestS3APrefetchingCacheFiles.teardown(ITestS3APrefetchingCacheFiles.java:85)

{code}