OCI Queue is now available in all commercial regions

We’re pleased to announce that Oracle Cloud Infrastructure (OCI) Queue service is now generally available in all OCI commercial regions, with the non-commercial regions following shortly. OCI Queue provides a serverless, high-performance messaging solution for asynchronous interprocess communication, allowing services and applications to be decoupled and event-driven. The service is priced on API calls, with the first million calls each month being free.

The service includes an intuitive user interface for configuring, creating, and managing queues, along with Terraform support. The service is supported with REST APIs and SDKs for multiple languages, including Java and Python, for not only sending and receiving messages on the queues but also configuring and managing the queues. With REST APIs, the service also supports the use of the STOMP protocol, and other messaging protocols get support in the future.

The Oracle Architecture Center and public GitHub repositories include example and referenceable implementations that you can deploy to see queues being used and see code putting the APIs and SDKs into use.

OCI Queue capabilities

The service provides the following features:

◉ Delivery assurance

◉ Automatic scaling based on demand

◉ Highly available with availability domain and fault zone redundancy

◉ OCI Queue messages are encrypted in flight and at rest.

◉ Implementation agnostic

◉ Provision of dead letter queues to hold messages that have failed delivery

◉ Strong access control managed through policies controlled by OCI Compartments and Identity and  Access Management (IAM) services

◉ Messages in batches to ensure efficiency

Consumption management

The consumption of messages provides the means to control their visibility. When one consumer takes a message, it isn’t visible to any other consumers but retained on the queue until the first consumer confirms successful receipt or is timed out. With this method, the consumer can change how long a message remains hidden if its transaction takes longer than expected.

The process uses the following steps:

1. A producer sends a message to the queue with the default message retention time. The producer receives confirmation that the Queue service received and stored the message.
2. Consumer A receives the message, which it is supposed to process within Visibility Timeout A.
3. Consumer B receives nothing because the only available message was already consumed by Consumer A.
4. Consumer A fails to process the message within Visibility Timeout A, so it updates the message to extend the visibility timeout.
5. Consumer B tries to receive a message again but can’t because the only available message was consumed and extended by Consumer A.
6. The extended visibility timeout elapses, and the message becomes visible again.
7. Consumer B tries to receive a message a third time. Consumer B receives the message, which is supposed to process within Visibility Timeout B.
8. Consumer A tries to receive the message but receives nothing because Consumer B consumed the message. Consumer A can no longer extend the message’s visibility timeout or delete the message.
9. Consumer B processes the message successfully and tries to delete the message from the queue. Consumer B receives confirmation that the message was permanently deleted, so it can’t be delivered to any other consumer.

Source: oracle.com