[
https://issues.apache.org/jira/browse/IGNITE-29116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-29116:
------------------------------------
Description:
ompute task and job callbacks run under the Operation Context they were started
with
Ignite Compute handles tasks and jobs the way thread pools and futures handle
runnables and listeners. A task or job is submitted, stored in an internal
collection, and later run by an arbitrary thread. So Compute has the same
Operation Context propagation problem we already solved for Ignite futures and
thread pools.
A task or job can also react to signals that arrive on other threads, such as a
cluster node leaving. Its phases can then run under an Operation Context that
belongs to whoever triggered the signal, not to the task initiator.
Affected paths:
- Job side (GridJobWorker):
- A queued job is activated, or rejected, by the collision SPI in the request
thread of another job.
- A running job is cancelled from another thread: by the collision SPI, or by
a task cancellation request.
- A job suspended with holdcc() is resumed by callcc() in whatever thread
calls it.
- ComputeJobMasterLeaveAware.onMasterNodeLeft runs in the discovery thread.
- Task side (GridTaskWorker): job responses, and with them ComputeTask.result()
and ComputeTask.reduce(), are processed in foreign threads. Examples are the
response synthesized from a node-left event (discovery thread), and a rejection
triggered by another task's job.
Before this change, only the security context was restored explicitly, and only
on some of these paths (ctx.security().withContext(secCtx) around job execution
and cancellation). Every other attribute came from whichever thread happened to
run the callback.
was:
Ignite Compute may handle tasks in the same way that thread pools and features
handle executables/listeners: tasks are submitted, stored in an internal
collection, and then started by an arbitrary thread. Therefore, we need to
solve the same Operation Context propagation problem that we solved for Ignite
Futures and thread pools.
Another aspect is that a Compute task may receive signals from other threads,
such as a cluster node left event, and react to them (e.g., by executing the
task's reduce phase). These scenarios should be reviewed to avoid situations
where a task phases are executed with an unexpected Operation Context that does
not belong to the task initiator.
> Fix Operation Context propagation for Ignite Compute
> -----------------------------------------------------
>
> Key: IGNITE-29116
> URL: https://issues.apache.org/jira/browse/IGNITE-29116
> Project: Ignite
> Issue Type: Task
> Reporter: Mikhail Petrov
> Priority: Major
>
> ompute task and job callbacks run under the Operation Context they were
> started with
> Ignite Compute handles tasks and jobs the way thread pools and futures handle
> runnables and listeners. A task or job is submitted, stored in an internal
> collection, and later run by an arbitrary thread. So Compute has the same
> Operation Context propagation problem we already solved for Ignite futures
> and thread pools.
> A task or job can also react to signals that arrive on other threads, such as
> a cluster node leaving. Its phases can then run under an Operation Context
> that belongs to whoever triggered the signal, not to the task initiator.
> Affected paths:
> - Job side (GridJobWorker):
> - A queued job is activated, or rejected, by the collision SPI in the
> request thread of another job.
> - A running job is cancelled from another thread: by the collision SPI, or
> by a task cancellation request.
> - A job suspended with holdcc() is resumed by callcc() in whatever thread
> calls it.
> - ComputeJobMasterLeaveAware.onMasterNodeLeft runs in the discovery thread.
> - Task side (GridTaskWorker): job responses, and with them
> ComputeTask.result() and ComputeTask.reduce(), are processed in foreign
> threads. Examples are the response synthesized from a node-left event
> (discovery thread), and a rejection triggered by another task's job.
> Before this change, only the security context was restored explicitly, and
> only on some of these paths (ctx.security().withContext(secCtx) around job
> execution and cancellation). Every other attribute came from whichever thread
> happened to run the callback.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
