When using RavenDB for important sales and purchase documents how do you know if your code is transactional and safe? That is a question I was asking myself and so I created RavenDBNetworkTests to allow testing of RavenDB with simulated network conditions. The network simulations are done via ToxiProxy. The repo and this blog post assume Windows running Linux docker containers but you could easily modify the scripts to be all Linux or all Windows.
How does it work?
After you pull down the repo the first step is changing license.env. You will need to have a community or developer license. Then you can execute run.ps1 to compose a few containers. The containers are 3 RavenDB nodes, ToxiProxy, and small app to configure the proxies. Once that is all done you can go to RavenDB studio via localhost ports 7071, 7072, and 7073. If you look at the RavenDB studio you can see the proxies are configured. The RavenDB http and tcp connections are all using proxies that can be manipulated independently.
Now that the cluster and proxies are setup you can start doing some experimentation. Create a DB via one of the nodes and test document. As a simple example you can run “add-latency.ps1” and then attempt to update the document on node 1. Then change it on node 2. Then change the document again on node 1. Another quick example to understand what is going on under the covers is to disable one of the nodes by running ‘disable-node.ps1’. Notice how Node A goes into “Rehab”. 
Then create some documents and enable the node again using ‘enable-node.ps1’. This could represent many performance or node switching scenarios. Also at anytime you can view or configure the proxies using http://localhost:8474/proxies. Another test scenario you could build for is where consensus can’t be met when you have multiple nodes down.
With that quick overview now you can start thinking of more real life situation where you want to save an important document multiple times and want to ensure it is written and not overwritten by replication. The main way to do this is cluster wide transactions but they are non trivial to implement. You could use this setup to build out the reliability you need in your application using cluster wide transactions and then make sure they work the way you want. ToxiProxy supports many languages so you could spin up your own unit tests in this project and run them while changing the network conditions for the tests scenarios you need.
Leave a Reply