Retry policy will be triggered when the server in charge of receiving the Monitor notification is not acknowledging the notification correctly. It’s the case if the response to the HTTP notification is anything else than an HTTP 2XX.

Retry policy is not made for data storage use! It is a remedial tool in case of service failure of the server where the notification should be received.

Policy Description #

This policy of retry has different parameters:

• When a message enters failure, it will be sent again until it succeeds, or retention time exceeded.
• The retry delay, periods of time between two retry attempts, is 10 seconds.
• Notifications are sent in batches, when 100 notifications are ready, they will be sent in a batch, even if the retry delay of 10 seconds has not been reached. Batches send notification in a JSON array in the HTTP body, specific headers and query parameters will not be available.
• After 3 days (72 hours) of retry policy, the message is deleted.

Maximum Retention Time #

After 3 days of retry the notification message is deleted. However, it’s still possible to retrieve vehicle data using the REST API within the normal period of 2 months.

After the first notification not processed, other notification messages being triggered in this monitor will also continue to be sent for 3 days after the moment they were triggered.

Enter Retry Policy #

Retry policy is applied if the server is not responding HTTP code 2XX (for example, another HTTP code or a time-out) to a notification send by the monitor.

The notification is stored, and it will be sent again according to the policy.

Get Out of Retry Policy #

To get out of retry policy the server needs to respond “2XX” to any new attempt to send the notification. If it happens, the monitor is removed from retry policy and all stored HTTP notifications are sent. Otherwise, messages are deleted but vehicle data are still available through the REST API.