Notary Load Balancing

Load balancing for notaries as mentioned in ha-notary-service-setup.rst is done in a round robin fashion on the client side by Artemis.

Notary workers in a cluster which share the same serviceLegalName register their IP addresses with the network map under said legal name. The node, whenever trying to resolve the legal name, will provide all the addresses to Artemis, which will handle forwarding to the appropriate notary worker.

While server side solutions are possible, client side was chosen for future flexibility. As any notary worker in the cluster might be an adversary and deny service, the client needs to have the ability to rotate to different notaries and go through each one, until a non faulty one is discovered.

As described in Notary Failover, the client node will retry the flow. That retry goes to Artemis, which because of round robin style of communication with the cluster, would send the flow to the next notary worker. For example client sends to notary worker 1, which becomes unavailable, client times out while waiting for respond and retries the flow automatically which now gets sent to notary worker 2. Note that the retry can also happen in Artemis if notary worker 1 becomes unavailable before acknowledging that it has received the flow message.

That is currently impossible.

If one Corda node sends multiple notarisation requests which try to spend the same state, there is no guarantee which will be processed first. While technically it should be first in first out, in reality it’s quite possible in the case of a HA notary that the first request gets sent to notary 1 and the second request gets sent to notary 2. If notary 2 processes the request faster the FIFO is not met and the request on notary 1 will error out. Such a race on a state shouldn’t normally be possible unless it’s done intentionally.

Was this page helpful?

Thanks for your feedback!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

We're sorry this page wasn't helpful. Let us know how we can make it better!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Create an issue

Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.