Users should be able to choose different retry strategies if a http request fails. The following policies should be availble:
RetryForever
No cap on maximum of attempts to send an event to the collector.
This policy might appear attractive where it is critical to avoid data loss, because it never deliberately drops events. However, it could cause a backlog of events in the buffered queue if the collector is unavailable for too long.
MaxAttempts
Drop events after failing to contact the collector within a fixed number of attempts
This policy can smooth over short outages of connection to the collector. Events will be dropped only if the collector is unreachable for a relatively long span of time. Dropping events can be a safety mechanism against a growing backlog of unsent events.
NoRetry
This is equivalent to MaxAttempts(1). It might be appropriate for snowplow pipelines using real-time event processing, for which late events are worthless.
Users should be able to choose different retry strategies if a http request fails. The following policies should be availble:
RetryForever
No cap on maximum of attempts to send an event to the collector.
This policy might appear attractive where it is critical to avoid data loss, because it never deliberately drops events. However, it could cause a backlog of events in the buffered queue if the collector is unavailable for too long.
MaxAttempts
Drop events after failing to contact the collector within a fixed number of attempts
This policy can smooth over short outages of connection to the collector. Events will be dropped only if the collector is unreachable for a relatively long span of time. Dropping events can be a safety mechanism against a growing backlog of unsent events.
NoRetry
This is equivalent to
MaxAttempts(1). It might be appropriate for snowplow pipelines using real-time event processing, for which late events are worthless.