Subscribing to Message in pub/sub

Subscribing to Message in pub/sub



21 February 2020

Brief introduction to Cloud Pub/Sub:

A Cloud Pub/Sub is one of the available services in the Google Cloud Platform, which provides a messaging transport system. It takes the data from many senders and transmits it to many receivers in an asynchronous manner. It guarantees the delivery of all the individual messages sent by the senders but the delivery in order isn’t guaranteed.

Let’s have a look at some important terms which are given below related to this before diving into subscribing to messages:

  • Publisher: It is a sender who wishes to send the messages.
  • Topic: It is a store where messages are fed by the publisher.
  • Subscription: It is an entity that queues up the messages and determines which subscribers are registered to receive the messages.
  • Subscriber: It is a receiver where the messages are arrived.

Now let’s have a look at how these messages are subscribed:

Subscribers are of 2 types:

  • Push subscribers: They use WebHook endpoints in order to get the data delivered.
  • Pull subscribers: They fetch the data for themselves by connecting to an HTTP(s) endpoint.


Subscription using installation of beta components:

  • To get started, if there isn’t any initial topic, a topic is created to publish messages. In order to do so, simply execute the command gcloud  beta pubsub topics create  <Topic_name> after installing beta components in Cloud shell.
  • Publisher sends a message to this created topic by execution of command: gcloud beta pubsub topics publish  <Topic_name> ”<message>”
  • Subscriber receives messages on an individual topic. To setup a subscriber for the above topic, execute the command gcloud beta pubsub subscriptions create –topic <Topic_name>  <Subscriber _name>
  • In order to see whether this message has been received, execute gcloud beta pubsub subscriptions pull –-auto-ack <Subscriber_name> as the subscriber acknowledges once the message is received. Once the acknowledgement is done, the message is removed from the queue in the subscription.

The message is delivered at least once to the subscriber and the Pub/Sub tries to deliver it repeatedly until an acknowledgement is received.

In this case, there won’t be any acknowledgement because the message was sent before the subscriber subscribed to a new topic. A subscriber must subscribe to a topic before publishing a message to it.

  • Now if we execute the command to send another message on the topic that subscriber has subscribed to, an acknowledgement will be received.

Subscribing to messages using python libraries:

In this method, we clone the python-docs-samples repository(from GitHub) which contains the python libraries. These libraries, in turn consist of and files in which methods for various operations like listing, creating, deleting  topics or subscriptions etc. are defined. These have different arguments to be passed in order to implement these operations on a publisher, topic, subscription or a receiver.  Here is how we do this:

Now, in order to list the subscriptions for a topic if the command is run without specifying the topic having subscriptions then an error message stating “too few arguments” is received. That means, subscription is done on a per topic basis. A topic name must be specified as an input argument if any operation related to subscription is done.

Given below are examples of the operations done while subscribing to messages:

  • Creating a topic: command- python create <Topic_name>
  • Listing the subscriptions: command- python  list <Topic_name> in the Cloud shell (without specifying the topic will throw an error)
  • Creating the subscription: Command- python create <Topic_ name> <Subscription_name>
  • Publishing a message: Command- python publish <Topic_name> <message>
  • Receiving the message: Command- python receive <Topic_name> <Subscription_name>
  • Deleting the subscription: Command- python delete <Topic_name> <subscription_name>

Blog Categories
Request a quote