[
https://issues.apache.org/jira/browse/IGNITE-28964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-28964:
--------------------------------------
Priority: Minor (was: Major)
> Investigate usage of GridJobSiblingImpl
> ---------------------------------------
>
> Key: IGNITE-28964
> URL: https://issues.apache.org/jira/browse/IGNITE-28964
> Project: Ignite
> Issue Type: Task
> Reporter: Vladimir Steshin
> Priority: Minor
> Labels: ISE-132
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The questions are:
> * Why we serialize both `{_}GridJobSiblingImpl#jobId{_}` and
> `{_}GridJobSiblingImpl#sesId{_}`{_}.{_} Do we need `{_}sesId{_}`?
> * Why `{_}GridJobSiblingImpl#sesId{_}` cannot be null (the assert in the
> constructor)?
> * Why we use entyre `{_}ComputeJobSibling{_}` / `{_}GridJobSiblingImpl{_}`
> in `{_}GridJobExecuteRequest{_}`? Looks like we need only sibling jobs ids
> * Do we need sibling sessions ids in `{_}GridJobExecuteRequest{_}`?
> * Is `{_}ComputeJobSibling#cancel(){_}` actually allowed on node where
> related compute task starts?
> * How we restore the impl. after transmission to other node, how
> `{_}cancel(){_}` works?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
