Receiving messages using Push

Subscribers can read messages from named-channels called Subscriptions. Each subscription can belong to a single topic. A topic though can have multiple subscriptions. If you are a subscriber and you want to receive messages published to a topic, the idea is that you should create a subscription to that topic. The subscription is the connection of the topic to a specific application, and its function is to receive and process messages published to the topic. Only messages published to the topic after the subscription is created are available to subscriber applications.

AMS supports both push and pull message delivery. In push delivery, the Messaging Service initiates requests to your subscriber application to deliver messages. In pull delivery, your subscription application initiates requests to the Pub/Sub server to retrieve messages.

In a push subscription, the push server sends a request to the subscriber application, at a preconfigured endpoint. The subscriber's HTTP response serves as an implicit acknowledgement: a success response indicates that the message has been successfully processed and the Pub/Sub system can delete it from the subscription; a non-success response indicates that the Pub/Sub server should resend it (implicit "nack"). To ensure that subscribers can handle the message flow, the Pub/Sub dynamically adjusts the flow of requests and uses an algorithm to rate-limit retries. The push server(s) are an optional set of worker-machines that are needed when the AMS wants to support push enabled subscriptions. It allows to decouple the push functionality from AMS api nodes They perform the push functionality for the messages of a push enabled subscription (consume->deliver→ack)/ Provide a gRPC interface in order to communicate with their api Provide subscription runtime status

Before you start

In order to get an account on the ARGO Messaging Service, submit a request through the ARGO Messaging Service account form

Upon account approval, you will receive information via e-mail about your new project along with an API token.

Manage a push Subscription

Step 1: Create a Push Enabled Subscription

This request creates a new subscription in a project with a PUT request. Whenever a subscription is created with a valid push configuration, the service will also generate a unique hash that should be later used to validate the ownership of the registered push endpoint, and will mark the subscription as unverified.

You may find more information from here Push Enabled Subscription

Step 2 : Verify ownership of a push endpoint

The owner of the push endpoint in order to start the communication with the AMS should verify the ownership of it. This is a simple step. Whenever a subscription is created with a valid push configuration, the AMS service also generates a unique hash. This hash should be later used to validate the ownership of the registered push endpoint, and will mark the subscription as verified.

You may find more information from here Verify ownership of a push endpoint

Step 3 : Modify Push Configuration

Sometimes the owner of the push endpoint needs to update the configuration of the push endpoint. The owner could update either the subscription_name or the pushConfig. The pushConfig configuration includes the pushEndpoint for the remote endpoint to receive the messages and the includes retryPolicy (type of retryPolicy and period parameters)

NOTE: Changing the push endpoint of a push enabled subscription, or removing the push configuration and then re-applying will mark the subscription as unverified and a new verification process should take place.

You may find more information from here Modify Push Configuration

Retry Policies

AMS Supports the following retry policies in PUSH endpoints.

Linear

In case of a linear retry policy, the consumption of the messages is repeated periodically with same period. For example, if the retry interval is set for 5 seconds, first retry operation is performed 5 seconds after the first response and then the next retry operation is performed 5 seconds after the second response and so on.

Creating a push enabled subscription with a linear retry policy and a period of 3000 means that you will be receiving message(s) every 3000ms.

Slowstart

If you decide to choose a retry policy of slowstart, you will be receiving messages with dynamic internals. The slowstart retry policy starts by pushing the first message(s) and then deciding the time that should elapse before the next push action.

• IF the message(s) are delivered successfully the elapsed time until the next push request will be halved, until it reaches the lower limit of 300ms.

• IF the message(s) are not delivered successfully the elapsed time until the next push request will be doubled, until it reached the upper limit of 1day.

So for example, the first push action will have by default a 1 second interval. If it successful the next push re request will happen in 0.5 seconds. If it is unsuccessful the next push request will happen in 2 seconds.