dennishuo commented on code in PR #1000:
URL: https://github.com/apache/polaris/pull/1000#discussion_r1966408700
##########
service/common/src/main/java/org/apache/polaris/service/task/TaskExecutorImpl.java:
##########
@@ -28,57 +27,47 @@
import java.util.concurrent.Executor;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
-import org.apache.polaris.core.PolarisConfigurationStore;
-import org.apache.polaris.core.PolarisDiagnostics;
-import org.apache.polaris.core.context.RealmContext;
+import org.apache.polaris.core.context.CallContext;
import org.apache.polaris.core.entity.PolarisBaseEntity;
import org.apache.polaris.core.entity.PolarisEntity;
import org.apache.polaris.core.entity.PolarisEntityType;
import org.apache.polaris.core.entity.TaskEntity;
import org.apache.polaris.core.persistence.MetaStoreManagerFactory;
import org.apache.polaris.core.persistence.PolarisMetaStoreManager;
-import org.apache.polaris.core.persistence.PolarisMetaStoreSession;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/**
* Given a list of registered {@link TaskHandler}s, execute tasks
asynchronously with the provided
- * {@link RealmContext}.
+ * {@link CallContext}.
*/
public class TaskExecutorImpl implements TaskExecutor {
private static final Logger LOGGER =
LoggerFactory.getLogger(TaskExecutorImpl.class);
private static final long TASK_RETRY_DELAY = 1000;
+ private final CallContext callContext;
private final Executor executor;
private final MetaStoreManagerFactory metaStoreManagerFactory;
- private final PolarisConfigurationStore configurationStore;
- private final PolarisDiagnostics diagnostics;
private final TaskFileIOSupplier fileIOSupplier;
- private final Clock clock;
private final List<TaskHandler> taskHandlers = new CopyOnWriteArrayList<>();
public TaskExecutorImpl(
+ CallContext callContext,
Review Comment:
Yeah looks like with the latest fix plumbing `ctx` through `handleTask` it
should work now. In general it's probably best to continue handling CallContext
somewhat explicitly because even though right now the "background processing"
is able to just be best-effort within the same process, the design of having
TaskEntity persistence really is supposed to reflect reliable task execution on
server failures.
In which case, we need a formal model for creating a "SystemCallContext" of
sorts that may or may not "impersonate" parts of the original call context that
resulted in the system event. And we'd need to be able to serialize such
CallContext state into the TaskEntity and restore it on server startup to
create the CallContext with which to perform the system tasks.
Incidentally, this also means there are intended flows that aren't
technically `@RequestScoped`.
--
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]
