You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the exporter helper puts failed (non-permanent error) requests back to the beginning of the queue only if retry_on_failure and persistent queue are enabled. There are a few problems with that:
There is no way to use the persistent queue and drop requests that the retry sender failed to deliver after several attempts
There is no way to configure the persistent queue with re-enqueueing but with disabled exponential backoff retry.
There is no way to configure re-enqueueing with the memory queue, which potentially still can be useful for someone who wants to make sure that requests are never dropped after reaching the queue as long as collector is up and running.
The queue sender (sending_queue configuration section) behavior is affected by the retry sender (retry_on_failure configuration section).
Proposed solution is to add an option to the sending_queue section:
// RequeueOnFailure indicates whether requests are requeued or dropped on non-permanent failures.// If true, a request failed with a non-permenent error will be put back in the queue and // retried after the current queue is drained.// If false (by default), items will be dropped after any failed send operation.// Setting this option to true means that the request will never leave the exporter queue until it's // successfully exported or failed with permanent error.// Keep in mind that this option is independent of the `retry_on_failure`, which consumes // requests from the queue and apply blocking exponential backoff retry mechanism.RequeueOnFailurebool`mapstructure:"requeue_on_failure"`
Introducing this option also requires making sure that the re-enqueue mechanism works well with the memory queue shutdown, which currently can lead to data races. See #8124
The text was updated successfully, but these errors were encountered:
Currently, the exporter helper puts failed (non-permanent error) requests back to the beginning of the queue only if retry_on_failure and persistent queue are enabled. There are a few problems with that:
sending_queue
configuration section) behavior is affected by the retry sender (retry_on_failure
configuration section).Proposed solution is to add an option to the
sending_queue
section:Introducing this option also requires making sure that the re-enqueue mechanism works well with the memory queue shutdown, which currently can lead to data races. See #8124
The text was updated successfully, but these errors were encountered: