Skip to content
This repository has been archived by the owner on Jan 21, 2022. It is now read-only.

Deal With Network Issues

Hristo Iliev edited this page Apr 12, 2018 · 13 revisions

Submitting usage documents or getting usage reports involves network operations. As with every network, failure is inevitable and the Resource Provider needs to take care of all network issues.

In this section, you can find several ways to deal with an unreliable network (circuit breaker, retry) and bandwidth, and latency problems (throttling).

Retrying Requests

Retrying a failed request is the easiest way to deal with network problems.

It is mandatory for Resource Providers to implement retry since reporting usage might rather fail than succeed due to a number of reasons (including but not limited to network and hardware issues, Abacus problems, CloudOps & DevOps updates).

Retrying a report puts some requirements on the Resource Providers. They need to persistently store the usage that was not successfully reported to guarantee that it is not lost.

However, not all the requests can be retried. For example, response 409/Conflict most commonly means:

  • you have already submitted that usage
  • you are trying to submit usage outside of the slack window

Another example, where you cannot simply retry, is the 404 error code. It usually means that Abacus does not know about a certain entity and retrying won't help in resolving the issue.

Abacus has the retry module that can help us with the retry task.

Circuit Breakers

Making a Resource Provider resilient requires you to isolate parts of your Resource Provider, to isolate from failing Abacus installation or to simply avoid failure cascades in a graph of function calls.

You can do that with the help of the breaker module. Java-based Resource providers can use the Hystrix library.

Abacus itself provides hystrix compatible streams for all its micro-services built with the help of perf and hystrix modules.

Throttling Requests

The number of requests is not limited and it can grow beyond the capabilities of the physical machine. This, in turn, results in network failures or VM/engine errors and crashes, depending on the used stack.

You can use connection pools, that is a dedicated client (that basically does the pooling).

Chaining Modules

Abacus modules can be chained. For example, in order to get a request that is throttled, retries and has breaker, simply use:

const retry = require('abacus-retry');
const breaker = require('abacus-breaker');
const throttle = require('abacus-throttle');
const request = require('abacus-request');

const reliableRequest = throttle(retry(breaker(request)));
<< Generate Usage Reports Best Practices >>

Related links:

Clone this wiki locally