Vladimir Ozerov created IGNITE-4240:
---------------------------------------
Summary: Review GridInternal usages.
Key: IGNITE-4240
URL: https://issues.apache.org/jira/browse/IGNITE-4240
Project: Ignite
Issue Type: Task
Components: compute
Affects Versions: 1.7, 1.8
Reporter: Vladimir Ozerov
Fix For: 2.0
We have {{@GridInternal}} annotation which manages which thread will execute
particular job - public pool or management pool. This annotation is applied to
some internal Ignite jobs.
There is strong evidence that it doesn't work in all places where we set it:
1) Some annotation is set on tasks and this is where everything appears to be
ok.
2) Some annotation is set on jobs. E.g {{GridCacheAdapter.SizeJob}}. In this
case annotation was ignored by parent {{GridCacheAdapter.SizeTask}} what caused
starvation described in IGNITE-4239. There are more places where we do that.
3) Sometimes it is set on closures or jobs which are passed to
{{GridClosureProcessor}}. E.g. looks at {{GridAffinityUtils.AffinityJob}}. It
is passed to {{GridClosureProcessor.callAsyncNoFailover}} where execution is
forced to happen in system pool (sick!).
To summarize: {{@GridInternal}} jobs and closures are expected to be executed
in management pool only, but in reality they can be executed in system, public
or management pool.
We need unified solution for this problem, so that any task, job, or closure
with this annotation is processed properly. Suggested solution:
1) If task is marked internal, all it's jobs must be executed in management
pool.
2) If certain job is marked internal, it must be executed in management pool.
3) If closure is marked internal, it must be executed in management pool.
4) All methods (~10) having {{boolean sys}} argument in
{{GridClosureProcessor}} must be reviewed as follows:
- If there are not public usages outside that class or all such usages have
{{system = false}}, then remove methods with flags and delegate decision to
task processor;
- If there are public usages ({{runLocalSafe}}, {{callLocalSafe}}), split every
such methods in two. First will always execute in system pool, second will make
decision based on annotation. This way we will not make mistakes in future.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)