IronMQ is a message queuing service for distributed cloud applications. It supports both pushing and pulling queues for message delivery within cloud applications and between systems. In the push method, the queue automatically pushes messages to one endpoint (unicast) or multiple endpoints (multicast). In the pull method, the message delivery occurs at intervals, and subscribing endpoints pull messages from the queue.
IronMQ also supports long polling, allowing developers to keep a connection open with a queue until a message is available. Support for pushing and pulling queues ensures faster message delivery to other systems, while the long polling helps eliminate empty responses.
How Did IronMQ come about?
Iron.io announced the release of IronMQ into public beta in December 2011. This service was made available during its beta period as a free trial for developers with messaging needs. IronMQ services were made available to the public in general release in Europe in February 2014, and United States just before, in January.
IronMQ’s aim was to offer developers an easy and reliable way to create data and event flow within cloud applications and between systems via its REST interface. With distributed cloud applications in mind, IronMQ comes with advanced features, including HTTPS transport, one-time FIFO delivery, message persistence, and cloud-optimized performance. Today, IronMQ is used by CNN, Twitter, Turner, Coinbase, HotelTonight, Hubble, Broadly, Parkly, among others.
How does IronMQ work?
As with most message queuing middleware, IronMQ features three major components:
Publishers (components that push messages to the queue)
Queues (components that retain or store pushed messages)
Subscribers/receiving endpoints (other components that receive messages from the queue)
However, its architectural design is somewhat different from other message queuing middleware out there. With IronMQ, a publisher creates a push queue and posts a message to the queue. IronMQ pushes the message from the queue to your queue endpoints (subscribers). The IronMQ service "reserves" the pushed message until acknowledged by the receiving endpoint (subscriber) or until it times out.
Subscribing endpoints receive the message either by pulling it from the IronMQ queue or by IronMQ pushing the message to them. The receiving endpoint responds with a 200 or 202 success response code to acknowledge the published message within the message timeout.
If there's no response code from the receiving endpoint within the specified timeout, the message is marked as 4xx/5xx failure and will be retried. IronMQ removes the acknowledged message from the queue or reserves it until deleted by the receiving endpoint, or the timeout is exceeded.
Note: 200 response code means the message is deleted/acknowledged and removed from the queue, while the 202 response code means the message is reserved until explicitly deleted or the message timeout elapses. 4xx or 5xx failure code means the queue will attempt to resend the push message to the endpoint. Retry default is 3 times; retry maximum is 100 times. Messages that fail to arrive after the maximum number of retries is exceeded get placed in another queue called "error queue" (this has to be set up by the publisher).
Technical Overview of IronMQ
IronMQ features a REST API that allows developers to access and integrate the IronMQ functionality into other applications. With the REST API, developers can create message queues, monitor message queues, and manage the number of messages that can go through applications.
There are also client libraries available in all major programming languages. The official client libraries for IronMQ REST/HTTP API include Go, Ruby, .NET, Java, PHP, Python, Node, and Rust. IronMQ also features some unofficial client libraries for their API, such as Apache Camel Component, and Clojure – clj-ironmq (by Yury Yantsevich).
IronMQ supports message sizes up to 256KB in any format. However, developers can manage IronMQ message content larger than 256KB using IronCache, which has a maximum size of 1MB.
IronMQ uses OAuth 2 (industry-standard authentication scheme) for its API account authorization. This scheme uses SSL to secure data in transit and authenticate API requests. IronMQ also uses HTTPS encryption by default for its API and all its access requests and client libraries to keep its accounts, services, and projects safe from common packet-interception attacks.
There's also an option for added protection of sensitive data in transit and at rest through client-level encryption of data payloads. IronMQ possesses many of the AWS and Rackspace security measures and certifications regarding VM security, network security, and physical security.
IronMQ integrates with popular tools such as Amazon EC2, Heroku, Red Hat OpenShift, Rackspace Cloud Servers, and Pivotal Web Services (PWS), among others.
IronMQ Pros
Fully-managed message queuing middleware service
Push, pull, and long polling support
Advanced security measures via SSL and OAuth
A dedicated queue for undelivered messages (error_queue)
One-time FIFO delivery
GDPR compliant
IronMQ Cons
× Sub-par documentation
Read more…
IronMQ – Reviews, Pros & Cons | Companies using IronMQ
Editor's Choice IronMQ: Overview and Review
IronMQ Push Queues – Reliable Message Delivery for the Cloud
Recommended Articles
Maximize the value of realtime analytics with Kafka and Ably
Learn how you can use Kafka and Ably to engineer a high-performance analytics pipeline that connects your backend to end-users at the network edge in realtime.
How to stream Kafka messages to Internet-facing clients over WebSockets
Kafka is used by a plethora of companies to power their realtime data streaming pipelines. Here, we explore how it can be used with WebSockets to stream data over the Internet.
ZeroMQ
ZeroMQ, an asynchronous message queue library aimed at building messaging middleware brokers or protocols for distributed or concurrent applications.
