solution: docs for access logging
This commit is contained in:
@@ -29,7 +29,7 @@ And for a request:
|
||||
- Is it for concrete data (_block #100_) or the latest (_get balance_)?
|
||||
- Is result a static value (_just block_) or may vary depending on network and node (_latest nonce_)?
|
||||
- Does it need to be repeated over multiple nodes (_broadcast transaction_)?
|
||||
- Request can also specify which subset of nodes should be able to execute the request by selecting node _Labels_ (see "link:08-quorum-and-selectors.adoc[Quorum and Selectors]")
|
||||
- Request can also specify which subset of nodes should be able to execute the request by selecting node _Labels_ (see "link:09-quorum-and-selectors.adoc[Quorum and Selectors]")
|
||||
|
||||
Based on these factors, Dshackle executes the request on a most optimal node.
|
||||
For most of the simple requests, it just gets a node that is synchronized to the point that must have a response for that particular request.
|
||||
@@ -43,7 +43,7 @@ It provides:
|
||||
- Routes only realy/alive upstreams, i.e., synchronized and with enough peers
|
||||
- Load Balancing
|
||||
- Request Retry on upstream errors
|
||||
- Local Caching (memory and Redis, see link:09-caching.adoc[Caching])
|
||||
- Local Caching (memory and Redis, see link:10-caching.adoc[Caching])
|
||||
- Broadcasting and Quorum for requests
|
||||
|
||||
=== gRPC protocol
|
||||
|
||||
Reference in New Issue
Block a user