Rating map is now accessible from Accounting.
ExtraCharges struct is accessible from Accounting.
RatingUnit fields that did not represent the id of another event cost struct
are now retrievable.
Add ees_success_ids and ees_failed_ids fields in reader config. The
former will be used to set EeIDs when the event processing returns
no error, while the latter will be used otherwise.
Add config sanity checks for the added options.
Remove Processed opts and everything related to them since they should
not be used anymore.
Fixed test compilation errors caused by the change.
Implemented functionality that handles reconnecting to the amqp server
and reinitializing the amqp channel in case of errors and timeouts. This
is handled by a goroutine created in the client constructor (it also
handles the initial connect/init).
Reconnects and reinits will use a fibonacci backoff strategy, and the
attempt amount and max waiting interval can be adjusted by the
'reconnects' and 'max_reconnect_interval' config options.
Messages that fail processing are now dropped instead of being requeued,
preventing infinite processing loops. However, this means that the
messages are lost. Handling failed messages will need to be addressed
separately.
'concurrent_requests' will now set the prefetch count. Setting the
prefetch count using the Qos function was able to replace our old
approach that was using channels. Default value is 1024 which,
according to the rabbitmq docs, 'runs into the law of diminishing
returns'. The recommended value is between 100-300. Source:
https://www.rabbitmq.com/confirms.html#channel-qos-prefetch-throughput
Fix test compilation errors and failing tests caused by these changes.
References #4160
They are separate for each configured reader.
Additional changes:
- rearrange config_defaults fields for ers/ees;
- add comment for RunDelay config option inside struct definition;
- improve comments for amqp opts in config_defaults.
Behind http.Header is just a map and it's not safe for concurrent use.
Before this change, a panic might have occurred when doing asynchronous
HTTP exports (applies to both *http_post and *http_json_map exporters).
Cloning the header before adding it to the HTTP request has fixed this
issue.
Slightly improved the test that found this data race.
