learnting commented on issue #4704:
URL: https://github.com/apache/polaris/issues/4704#issuecomment-4691010790
Thank you for your reply.
I'm investigating the error s3 throw "Unable to execute HTTP request:
Timeout waiting for connection from pool" like #3462.
So I tried using `polaris.storage.max-http-connections=128` and
`polaris.tasks.max-concurrent-tasks=64` to resolve the issue.
Now we confirm the s3 thread pool size is 50, and I've found many thread
stacks using Arthas, as shown below:
```
[arthas@1]$ thread 29641
"executor-thread-409" Id=29641 WAITING on
java.util.concurrent.CompletableFuture$Signaller@2df4a1e
at [email protected]/jdk.internal.misc.Unsafe.park(Native Method)
- waiting on java.util.concurrent.CompletableFuture$Signaller@2df4a1e
at
[email protected]/java.util.concurrent.locks.LockSupport.park(LockSupport.java:221)
at
[email protected]/java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1864)
at
[email protected]/java.util.concurrent.ForkJoinPool.unmanagedBlock(ForkJoinPool.java:3780)
at
[email protected]/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3725)
at
[email protected]/java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1898)
at
[email protected]/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2072)
at
org.apache.polaris.service.task.ManifestFileCleanupTaskHandler.cleanUpManifestFile(ManifestFileCleanupTaskHandler.java:106)
at
org.apache.polaris.service.task.ManifestFileCleanupTaskHandler.handleTask(ManifestFileCleanupTaskHandler.java:66)
at
org.apache.polaris.service.task.TaskExecutorImpl.handleTask(TaskExecutorImpl.java:235)
at
org.apache.polaris.service.task.TaskExecutorImpl.handleTaskWithTracing(TaskExecutorImpl.java:295)
at
org.apache.polaris.service.task.TaskExecutorImpl_Subclass.handleTaskWithTracing$$superforward(Unknown
Source)
at
org.apache.polaris.service.task.TaskExecutorImpl_Subclass$0.apply(Unknown
Source)
```
First, I thought that since `ManifestFiles.read` returns a `Closeable`
object, it should be closed using `try-with-resources`.
Then I suspected that `ManifestFiles.read` might internally hold an S3 HTTP
connection, and the manifest reads generated by many delete table tasks might
be consuming all the S3 HTTP threads, causing the delete data file task to be
unable to acquire an S3 HTTP thread, resulting in this error.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
