Retry usage guidance
Consider the following guidelines when using retries in your MicroServices
- If you are using the REST API for inter-(micro)-service communication, retry the operation if the result code is 429 (Too Many Requests) or an error in the 5xx range. Do not retry for any other errors.
- For 429 errors, only retry after the time indicated in the Retry-After header.
- For 5xx errors, use exponential back-off, with the first retry at least 5 seconds(?) after the response.
- Do not retry on errors other than 429 and 5xx.
Continuous integration (CI) is the practice of automating the integration of code changes from multiple contributors into a single software project. It’s a primary DevOps best practice, allowing developers to frequently merge code changes into a central repository where builds and tests then run. Automated tools are used to assert the new code’s correctness before integration.
A source code version control system is the crux of the CI process. The version control system is also supplemented with other checks like automated code quality tests, syntax style review tools, and more.
In this blog post, you will witness how multi-core CPU executes different processes and do context switching.
We will use the following program, this program merely takes input from the user and prints input string after some time periodically.
I presume after compiling the above file, we get the output file: ‘OSPlayground.exe’.
Now open a command prompt and navigate to the path that contains the above binary. Run the following command and witness the magic.
Command to use: start /b OSPlayground && OSPlayground
The command prompt will ask you to enter the string a couple of times since we executed the program twice.
I had inputted EARTH! for the first process from the command prompt and MARS! for another one.
The above program is executed on a multicore processor.