You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/internal/DistributedArchitectureGuide.md
-44Lines changed: 0 additions & 44 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,50 +22,6 @@ See the [Javadocs for `ActionListener`](https://github.com/elastic/elasticsearch
22
22
23
23
(TODO: add useful starter references and explanations for a range of Listener classes. Reference the Netty section.)
24
24
25
-
### REST Layer
26
-
27
-
The REST and Transport layers are bound together through the `ActionModule`. `ActionModule#initRestHandlers` registers all the
28
-
rest actions with a `RestController` that matches incoming requests to particular REST actions. `RestController#registerHandler`
29
-
uses each `Rest*Action`'s `#routes()` implementation to match HTTP requests to that particular `Rest*Action`. Typically, REST
30
-
actions follow the class naming convention `Rest*Action`, which makes them easier to find, but not always; the `#routes()`
31
-
definition can also be helpful in finding a REST action. `RestController#dispatchRequest` eventually calls `#handleRequest` on a
32
-
`RestHandler` implementation. `RestHandler` is the base class for `BaseRestHandler`, which most `Rest*Action` instances extend to
33
-
implement a particular REST action.
34
-
35
-
`BaseRestHandler#handleRequest` calls into `BaseRestHandler#prepareRequest`, which children `Rest*Action` classes extend to
36
-
define the behavior for a particular action. `RestController#dispatchRequest` passes a `RestChannel` to the `Rest*Action` via
37
-
`RestHandler#handleRequest`: `Rest*Action#prepareRequest` implementations return a `RestChannelConsumer` defining how to execute
38
-
the action and reply on the channel (usually in the form of completing an ActionListener wrapper). `Rest*Action#prepareRequest`
39
-
implementations are responsible for parsing the incoming request, and verifying that the structure of the request is valid.
40
-
`BaseRestHandler#handleRequest` will then check that all the request parameters have been consumed: unexpected request parameters
41
-
result in an error.
42
-
43
-
### How REST Actions Connect to Transport Actions
44
-
45
-
The Rest layer uses an implementation of `AbstractClient`. `BaseRestHandler#prepareRequest` takes a `NodeClient`: this client
46
-
knows how to connect to a specified TransportAction. A `Rest*Action` implementation will return a `RestChannelConsumer` that
47
-
most often invokes a call into a method on the `NodeClient` to pass through to the TransportAction. Along the way from
48
-
`BaseRestHandler#prepareRequest` through the `AbstractClient` and `NodeClient` code, `NodeClient#executeLocally` is called: this
49
-
method calls into `TaskManager#registerAndExecute`, registering the operation with the `TaskManager` so it can be found in Task
50
-
API requests, before moving on to execute the specified TransportAction.
51
-
52
-
`NodeClient` has a `NodeClient#actions` map from `ActionType` to `TransportAction`. `ActionModule#setupActions` registers all the
53
-
core TransportActions, as well as those defined in any plugins that are being used: plugins can override `Plugin#getActions()` to
54
-
define additional TransportActions. Note that not all TransportActions will be mapped back to a REST action: many TransportActions
55
-
are only used for internode operations/communications.
56
-
57
-
### Transport Layer
58
-
59
-
(Managed by the TransportService, TransportActions must be registered there, too)
60
-
61
-
(Executing a TransportAction (either locally via NodeClient or remotely via TransportService) is where most of the authorization & other security logic runs)
62
-
63
-
(What actions, and why, are registered in TransportService but not NodeClient?)
64
-
65
-
### Direct Node to Node Transport Layer
66
-
67
-
(TransportService maps incoming requests to TransportActions)
Copy file name to clipboardExpand all lines: docs/internal/GeneralArchitectureGuide.md
+45-1Lines changed: 45 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,50 @@
1
1
# General Architecture
2
2
3
-
## Transport Actions
3
+
# REST and Transport Layers
4
+
5
+
### REST Layer
6
+
7
+
The REST and Transport layers are bound together through the `ActionModule`. `ActionModule#initRestHandlers` registers all the
8
+
rest actions with a `RestController` that matches incoming requests to particular REST actions. `RestController#registerHandler`
9
+
uses each `Rest*Action`'s `#routes()` implementation to match HTTP requests to that particular `Rest*Action`. Typically, REST
10
+
actions follow the class naming convention `Rest*Action`, which makes them easier to find, but not always; the `#routes()`
11
+
definition can also be helpful in finding a REST action. `RestController#dispatchRequest` eventually calls `#handleRequest` on a
12
+
`RestHandler` implementation. `RestHandler` is the base class for `BaseRestHandler`, which most `Rest*Action` instances extend to
13
+
implement a particular REST action.
14
+
15
+
`BaseRestHandler#handleRequest` calls into `BaseRestHandler#prepareRequest`, which children `Rest*Action` classes extend to
16
+
define the behavior for a particular action. `RestController#dispatchRequest` passes a `RestChannel` to the `Rest*Action` via
17
+
`RestHandler#handleRequest`: `Rest*Action#prepareRequest` implementations return a `RestChannelConsumer` defining how to execute
18
+
the action and reply on the channel (usually in the form of completing an ActionListener wrapper). `Rest*Action#prepareRequest`
19
+
implementations are responsible for parsing the incoming request, and verifying that the structure of the request is valid.
20
+
`BaseRestHandler#handleRequest` will then check that all the request parameters have been consumed: unexpected request parameters
21
+
result in an error.
22
+
23
+
### How REST Actions Connect to Transport Actions
24
+
25
+
The Rest layer uses an implementation of `AbstractClient`. `BaseRestHandler#prepareRequest` takes a `NodeClient`: this client
26
+
knows how to connect to a specified TransportAction. A `Rest*Action` implementation will return a `RestChannelConsumer` that
27
+
most often invokes a call into a method on the `NodeClient` to pass through to the TransportAction. Along the way from
28
+
`BaseRestHandler#prepareRequest` through the `AbstractClient` and `NodeClient` code, `NodeClient#executeLocally` is called: this
29
+
method calls into `TaskManager#registerAndExecute`, registering the operation with the `TaskManager` so it can be found in Task
30
+
API requests, before moving on to execute the specified TransportAction.
31
+
32
+
`NodeClient` has a `NodeClient#actions` map from `ActionType` to `TransportAction`. `ActionModule#setupActions` registers all the
33
+
core TransportActions, as well as those defined in any plugins that are being used: plugins can override `Plugin#getActions()` to
34
+
define additional TransportActions. Note that not all TransportActions will be mapped back to a REST action: many TransportActions
35
+
are only used for internode operations/communications.
36
+
37
+
### Transport Layer
38
+
39
+
(Managed by the TransportService, TransportActions must be registered there, too)
40
+
41
+
(Executing a TransportAction (either locally via NodeClient or remotely via TransportService) is where most of the authorization & other security logic runs)
42
+
43
+
(What actions, and why, are registered in TransportService but not NodeClient?)
44
+
45
+
### Direct Node to Node Transport Layer
46
+
47
+
(TransportService maps incoming requests to TransportActions)
0 commit comments