adrian-skybaker commented on issue #12220:
URL: https://github.com/apache/iceberg/issues/12220#issuecomment-2961365382
Hmm there are a lot of executors. Not thinking about it too deeply, two
possible directions:
1. Allow injection of a custom "ThreadPools" factory that allowed an
implementer to provide their own responses to `newWorkerPool` calls
- would require this to move away from being a static class
- the callers wouldn't really know what each executor is for, so there'd
not be any control over anything fine grained or order between executors. But
you could at least control broadly when Iceberg is shutdown (and it seems
Iceberg itself isn't managing the shutdown order in any particular way).
1. Follow the path of `org.apache.iceberg.SnapshotUpdate#scanManifestsWith`,
which allows each specific executor to be injected and controlled.
(1) is probably a simpler, lower level change, and it at least allows an
hosting app to control when iceberg is shutdown overall.
But I'm not sure what the preferred long term state would be. And it seems
possible that if you truly want to achieve fully graceful shutdown, you mind
find the order within the many iceberg executors is actually important, instead
of what I assume is the current non-deterministic order, if its based on
shutdown hooks.
--
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: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
