[
https://issues.apache.org/jira/browse/IGNITE-29116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-29116:
------------------------------------
Description:
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:
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.
> 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
> Assignee: Mikhail Petrov
> Priority: Major
>
> 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)
