OCI Queue is a highly available, high-throughput queue service capable of ingesting millions of messages per second. Users can publish, consume, and delete messages in Queue and also update the visibility of a message.
OCI Queue supports RESTful APIs with SDKs as well as STOMP.
The Queue supports standard queues (best-effort ordering). FIFO queues (strict ordering) is a future feature, and we don’t yet have a timeline for it. Please raise a support request or communicate with your OCI account manager if this is a requirement.
OCI Queue offers an SLA of 99.9% uptime with a maximum of seven days retention for messages.
You can increase some limits by raising a support request.
A throttling mechanism is activated when the following thresholds are exceeded:
Parameter | Customer soft limit |
---|---|
Throughput throttle limit | 10MB/sec ingress and 10MB/sec data egress per queue (soft) |
Example code can be found in the Oracle DevRel GitHub repository, or follow the following steps to configure your IDE.
com.oracle.oci.sdk
oci-java-sdk-queue
3.2.0
Some SDK features are demonstrated in examples included in the public GitHub repositories for OCI Queue.
We provide the following APIs:
Queue Management APIs
Messaging APIs
Details about API errors are in the documentation.
The purge call is eventually consistent; what this means is that it will delete all messages published before the purge call, but it might also delete some messages published while the queue is in the purging state (more strictly in Updating state with Purging lifecycle state details). The PutMessages call is not blocked during the purge operation, but its messages may be deleted.
It is guaranteed that purged messages will not be returned by the GetMessages call and will not affect the queue statistics. Still, the message deletion process is asynchronous and may take some time. During that time, update and delete operations for the purged messages will succeed, provided you have a valid receipt.
No, the client should invoke the DeleteMessage API to delete a message after successfully processing it. Otherwise, the message will be returned to the queue (after a visibility timeout) and returned during a subsequent Get request.