[
https://issues.apache.org/jira/browse/IGNITE-12448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17020946#comment-17020946
]
Alexey Goncharuk commented on IGNITE-12448:
-------------------------------------------
[~gvvinblade], I have one suggestion wrt to code organization based on general
ideas from [~akalashnikov]:
Right now it looks like that {{CalciteQueryProcessor}} is becoming both a
wiring component which connects various pieces together, and also executes some
important logic. This makes it impossible to test the logic without having an
IgniteKernal instance.
I would separate it the following way:
* Move {{locals}} and {{remotes}} maps to either exchange service or messaging
service. These maps are a part of communication subsystem, so the processor
should not be aware of it and should not manage it
* Separate all execution-related logic from CalciteQueryProcessor to a
separate class which does not depend on {{KernalContext}} and accepts only
interfaces. This way you can test this logic by mocking both all remote nodes
or by simulating remote nodes without actual Ignite start
* The {{CalciteQueryProcessor}} will just wire components that it pulls from
contexts, setup listeners, etc.
> Calcite integration. Communication protocol.
> --------------------------------------------
>
> Key: IGNITE-12448
> URL: https://issues.apache.org/jira/browse/IGNITE-12448
> Project: Ignite
> Issue Type: Task
> Components: sql
> Reporter: Igor Seliverstov
> Assignee: Igor Seliverstov
> Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We need to introduce a communication protocol between query fragments in
> scope of query execution.
> * Protocol should have Push semantics with back pressure ability
> * Protocol have to provide ordering guaranties - the data batches processed
> in same order they sent to remote node.
> * Protocol have to provide delivery guaranties.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
