ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-19 04:57:58 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Add documentation on clearing network map cache (#3280)

Browse Source 
Add documentation on clearing network map cache

CORDA-1562
This commit is contained in:
Katarzyna Streich 2018-05-31 17:44:38 +01:00 committed by GitHub
parent 34a480d7e3
commit 74fd5b9e9d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 26 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
docs/source/messaging.rst
View File

@ -24,21 +24,17 @@ Network Map Service
Supporting the messaging layer is a network map service, which is responsible for tracking public nodes on the network.
Nodes have an internal component, the network map cache, which contains a copy of the network map (which is just a
document). When a node starts up its cache fetches a copy of the full network map, and requests to be notified of
changes. The node then registers itself with the network map service, and the service notifies subscribers that a new
node has joined the network. Nodes do not automatically deregister themselves, so (for example) nodes going offline
briefly for maintenance are retained in the network map, and messages for them will be queued, minimising disruption.
Nodes have an internal component, the network map cache, which contains a copy of the network map (which is backed up in the database
to persist that information across the restarts in case the network map server is down). When a node starts up its cache
fetches a copy of the full network map (from the server or from filesystem for development mode). After that it polls on
regular time interval for network map and applies any related changes locally.
Nodes do not automatically deregister themselves, so (for example) nodes going offline briefly for maintenance are retained
in the network map, and messages for them will be queued, minimising disruption.
Nodes submit signed changes to the map service, which then forwards update notifications on to nodes which have
requested to be notified of changes.
The network map currently supports:
* Looking up nodes by service
* Looking up node for a party
* Suggesting a node providing a specific service, based on suitability for a contract and parties, for example suggesting
an appropriate interest rates oracle for an interest rate swap contract. Currently no recommendation logic is in place.
Additionally, on every restart and on daily basis nodes submit signed `NodeInfo`s to the map service. When network map gets
signed, these changes are distributed as new network data. `NodeInfo` republishing is treated as a heartbeat from the node,
based on that network map service is able to figure out which nodes can be considered as stale and removed from the network
map document after `eventHorizon` time.
Message queues
--------------

16
docs/source/network-map.rst
View File

@ -173,3 +173,19 @@ shell (see :doc:`shell`):
If the administrator does not accept the update then next time the node polls network map after the deadline, the
advertised network parameters will be the updated ones. The previous set of parameters will no longer be valid.
At this point the node will automatically shutdown and will require the node operator to bring it back again.
Cleaning the network map cache
------------------------------
Sometimes it may happen that the node ends up with an inconsistent view of the network. This can occur due to changes in deployment
leading to stale data in the database, different data distribution time and mistakes in configuration. For these unlikely
events both RPC method and command line option for clearing local network map cache database exist. To use them
you either need to run from the command line:
.. code-block:: shell
java -jar corda.jar --clear-network-map-cache
or call RPC method `clearNetworkMapCache` (it can be invoked through the node's shell as `run clearNetworkMapCache`, for more information on
how to log into node's shell see :doc:`shell`). As we are testing and hardening the implementation this step shouldn't be required.
After cleaning the cache, network map data is restored on the next poll from the server or filesystem.