[
https://issues.apache.org/jira/browse/IGNITE-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694439#comment-16694439
]
Vladimir Ozerov commented on IGNITE-6173:
-----------------------------------------
[~jooger], in general I do not understand the idea.
{{GridCacheProcessor.createMissingQueryCaches}} is still there. Retries in DDL
are still there. But the whole ticket was about removing them. Also I do not
understand why we need to maintain a map of "lazy caches". From what I know,
correct implementation should be as follows:
1) When cache is created on data node - nothing changes
2) When cache is registered on non-affinity node - it still goes through
exchange thread (or main thread for static caches). In this case we should
always use client counterparts of indexes and tables, and never rely on
"GridCacheContext", right?
Could you please elaborate on this? May be there are some obstacles I am not
aware about.
Please also find several minor comments below:
1) New tests must reside in {{IgniteBinaryCacheQueryTestSuite}}
2) {{H2TreeNoDataIndex.segmentsCount}} - we should either throw an exception
here, if this method is not meant to be called on a client, or return correct
number of segments.
3) {{H2TreeNoDataIndex.getCost}},
{{H2TreeNoDataIndex.getRowCountApproximation}} - obvious code duplication.
Should be moved to common abstract class (probablty not GridH2IndexBase, but a
new one in hierarchy)
4) {{H2TreeNoDataIndex.canGetFirstOrLast}} - same as p.2. Either exception or
correct value, which is {{true}}, not {{false}}.
5) {{H2TreeNoDataIndex.destroy}} - why not delegating to parent?
6) {{H2TreeNoDataIndex}} - lets move common exception creation routine
("Shouldn't be invoked, due to it's not affinity node") to a common method to
avoid duplication.
7) {{H2TreeNoDataIndex}} - I would rename it to {{H2TreeClientIndex}} or so, to
stress that this is not a strange kind of index without data (doesn't make
sense), but an index on a non-affinity node.
> SQL: do not start caches on client nodes
> ----------------------------------------
>
> Key: IGNITE-6173
> URL: https://issues.apache.org/jira/browse/IGNITE-6173
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
> Affects Versions: 2.1
> Reporter: Vladimir Ozerov
> Assignee: Yury Gerzhedovich
> Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
>
> When cache is started, this even is distributed through custom discovery
> message. Server nodes start the cache, client nodes do nothing until cache is
> requested explicitly. At the same time H2 database objects are created only
> when cache is really started.
> For this reason query parsing could lead to {{TABLE NOT FOUND}}, {{INDEX NOT
> FOUND}}, etc. errors. If such exception is observed, we force start of all
> known cache on a client and then retry. See
> {{GridCacheProcessor#createMissingQueryCaches}} method.
> First, client node cache start leads to another custom discovery message. So
> query performance may suffer. Second, this is not needed! We already have all
> necessary cache info in discovery.
> Let's try to find a way to use available discovery data and do not start
> cache on a client for SQL query execution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
