See HDFS-11063 for a similar proposal I've created on the HDFS NameNode side.
For example, upon entering a public S3A method, we could append useful information to the thread name, such as the user, the start time of the operation and the file path argument. This information would be visible in the thread names when running jstack. That way, we could see that not only is a thread spending a long time in a globStatus call, but also which user is making the call, which path is referenced, and the start time.
This proposal would get trickier in combination with some of the plans around asynchronous and parallel execution. We'd need to pass along that contextual information to all of the threads that make up the high-level operation.
It's important that after the S3A operation completes, we restore the prior value of the thread name. S3A is called from user applications that own the lifecycle of the thread. If applications have set meaningful information into the thread name already, then we don't want that to remain changed after the thread exits the S3A code.
See HDFS-11063 for a similar proposal I've created on the HDFS NameNode side.
For example, upon entering a public S3A method, we could append useful information to the thread name, such as the user, the start time of the operation and the file path argument. This information would be visible in the thread names when running jstack. That way, we could see that not only is a thread spending a long time in a globStatus call, but also which user is making the call, which path is referenced, and the start time.
This proposal would get trickier in combination with some of the plans around asynchronous and parallel execution. We'd need to pass along that contextual information to all of the threads that make up the high-level operation.
It's important that after the S3A operation completes, we restore the prior value of the thread name. S3A is called from user applications that own the lifecycle of the thread. If applications have set meaningful information into the thread name already, then we don't want that to remain changed after the thread exits the S3A code.