Simulating network timeouts with toxiproxy

Goal: Simulate how a Node.js application reacts to timeouts.

Solution: Use toxiproxy and its timeout “toxic” with the value of 0, i.e. the connection won’t close, and data will be delayed until the toxic is removed.

The steps:

1. Start toxiproxy, exposing the port 6666 that we intend to use as localhost:6666:

docker pull shopify/toxiproxy
docker run --name=toxiproxy --rm --expose 6666 -p 6666:6666 -it shopify/toxiproxy

(If I was on Linux and not OSX then I could use --net=host and wouldn’t need to expose and/or map the port.)

1. Tell toxiproxy to serve request att 6666  via an upstream service:

docker exec -it toxiproxy /bin/sh
/ # cd /go/bin/
/go/bin # ./toxiproxy-cli create upstream -l 0.0.0.0:6666 -u google.com:443

1. Modify your code to access the local port 6666 and test that everything works.

Since we want to access Google via HTTPS, we would get a certificate error when accessing it via localhost:6666 so we will add an alias to our local s /etc/hosts:

127.0.0.1 proxied.google.com

and use
https://proxied.google.com:6666 in our connecting code (instead of the https://google.com:443 we had there before). Verify that it works and the code gets a response as expected.

1. Tell toxiproxy to have an infinite timeout for this service

Continuing our toxiproxy configuration from step 2:

./toxiproxy-cli toxic add -t timeout -a timeout=0 upstream

(Alternatively, e.g. timeout=100; then the connection will be closed after 100 ms.)

1. Trigger your code again. You should get a timeout now.

Tip: You can simulate the service being down via disabling the proxy:

./toxiproxy-cli toggle upstream

Advertisements

2015 in review

The WordPress.com stats helper monkeys prepared a 2015 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 200,000 times in 2015. If it were an exhibit at the Louvre Museum, it would take about 9 days for that many people to see it.

Click here to see the complete report.

NDC: Async and Streaming JavaScript, We’re All Doing it Wrong! (Promises, Streams, Rx)

By Matthew Podwysocki

Events

Lot of work (setup, remove listeners …), not composable.

Promises

No way to abort promise in progress. (Me: has to remember to check for errors: then(onOk, onError).)

No try-catch-finally; only try-catch.

Streams

Node: Stream 1 were terrible (pause/resume unusable, data sent before ready, …).

Why do companies fail at adopting Functional Programming?

According to the NDC Oslo talk Lean and Functional Programming by Bryan Hunter, these are the reasons why companies fail to adopt FP:

• They say “our developers aren’t smart enough” (to use F#, Erlang) [they should invest in their education!]
• Culture of hiding problems => little incentive to adopt a paradigm that solves/prevents them if they’re invisible
• Overburden => not time
• Implementing changes (FP) without first proving them (PDCA) – blindly rewriting something in F#/… can fail; it’s better to have a value-proposition hypothesis and prove it with a limited experiment first
• The prioritise short-term (e.g. fire-fighting) over long-term (removing the root causes of problems)

Tip for driving FP adoption: Find a pragmatist in pain – e.g. a business person experiencing problems that FP could have prevented.

Fix Shell Script Run via SSH Hanging (Jenkins)

There is an important difference between running a script manually (ssh machine; machine$ ./script.sh) and running it via ssh (ssh machine < script.sh): in the letter case the connection will not close when the script finishes but will stay open until stdout/stderr are closed or a timeout occurs. In Jenkins it will therefore seem as if the script hangs.

So if your shell scripts starts any background job, make sure to redirect all its output to somewhere:

nohup some-background-task &> /dev/null   # No space between & and > !

This has bitten me when trying to deploy an application from the Jenkins CI using SSH and a shell script.

References: http://www.snailbook.com/faq/background-jobs.auto.html

The blog’s year 2014 in review

The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 170,000 times in 2014. If it were an exhibit at the Louvre Museum, it would take about 7 days for that many people to see it.

Click here to see the complete report.

Connect Tunnelblick to VPN automatically after wake up

Need: Make sure that VPN is always running except when at work.

Partial solution: Make sure VPN is always running with “connect when computer starts” and using an AppleScript to connect after waking up from sleep. Disconnect manually when at work.

Future: Check the current location (wifi name? IP?) and do not connect when at work.

Petitioning EU to act against Russian aggression in Ukraine

As a citizen of a country that has been invaded by Hilter in 1938 under the pretext of protecting local Germans and again invaded by Russia in 1968, I cannot watch another such invasion and annexation taking place in Europe while EU does little of any consequences.

Please consider signing the petition to EU to act against Russian aggression with all the political and economical power it has, even if – oh the horror – will cost our wallets too.

Click here to join:
European Union, Catherine Ashton, Herman van Rompuy: Act on Ukraine. Immediately!

Protected: JavaServer Faces Are Evil (draft)

This content is password protected. To view it please enter your password below:

Password:

2013 in review

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 140,000 times in 2013. If it were an exhibit at the Louvre Museum, it would take about 6 days for that many people to see it.

Click here to see the complete report.