Differences between Queues and Topics.

Queues Topics Messaging paradigm Implements point-to-point messaging Implements publish-subscribe messaging Each message sent on a queue can have one Each message sent on a topic can have zero or and only one receiver more receivers Message persistence Reliability Wildcards A message sent on a queue with persistent delivery mode is always written to the disk by EMS before it is acknowledge to the sender User can not receive (create receiver) on wildcard queues User can not send on wildcard queues If queue foo.bar is not in the configuration file, then you can send on queue foo.bar if the parent queue exists in configuration file and you have proper access control If a queue has no started receivers, the EMS server can not enforce flow control of that queue. Flow Control is disengaged when there are no receivers on a queue. A message sent on a topic will be written to the disk only if it is sent with persistent delivery mode and it has at least one durable subscriber. User can subscribe to wildcard topics User can not publish to wildcard topics If topic foo.bar is not in the configuration file, then you can publish to topic foo.bar if the parent topic exists in configuration file and you have proper access control If a topic has inactive durable subscriptions or no current subscribers, the server can not enforce flow control for that topic. For topics, if flow control is set on a specific topic (for example foo.bar), then flow control is enforced as long as there are subscribers to that topic or any parent topic (for example, if there are subscribers to foo.*) For global topics where messages are routed between the servers, flow control can be specified for a topic on either the server where messages are produced or the server where messages are received

Flow control

Routes and flow control

Flow control is not relevant for queue messages that are routed to another server.

Routes

Queues do not support multi-hop routing Topics support both single hop full mesh as well as because of the need to coordinate delivery to multi hop routing multiple receivers. At most one hop either side of the Queue owning server is supported. Queue receivers can improve performance by Prefetch is not supported for Topics. fetching a batch of messages at once. Queue receivers can load-balance with nonexclusive queues. Load-balancing is not supported for Topics. Multiple Topic subscribers will receive the same sets of messages.

Message Prefetch Receiver LB

Multiple Consumers

Inbound message should be bridged to Multiple durable subscribers could subscribe to a multiple queues (1 for each subscribing single topic. Messages are written only once to the application), if multiple subscribing applications data store, even if there are multiple subscribers. are interested in the same message. Following When there are multiple durable subscribers on a this pattern will lead to multiple message writes topic and one of the subscribers is Offline, EMS to the different bridged queues. holds the messages for the offline subscriber and acks from all other active subscribers. This may degrade the performance of EMS server, if the durable subscribers fall apart with message consumption. Queue receivers can automatically failover from one to another with exclusive queues. When the maxbytes is reached for a queue, message producer will receiver an error. Failover from one receiver to another is not supported for Topics. In a scenario with multiple durable subscribers, when the maxbytes is reached for a single durable topic subscriber, message producer will not receive an error. This is because other durable subscribers might have not reached the maxbytes and can accept messages.

Receiver HA maxBytes

Pub/sub Latency

At application start up time, the order in which the receivers and senders are started does not matter, as the messages are retained in the server till the receivers consume it. If the application consuming from a queue is slow or takes long time for processing the message, multiple queue receivers could be started to avoid message back up in the server. Message that do not meet the client selector criteria are retained in the queues.

To avoid message loss, topic subscribers or subscribers creating dynamic durables should be started before the publishers send messages. Or static durables should be created in the server. In case of a slow subscriber, messages will be backed up in the EMS server. This is because messages cannot be distributed across multiple topic subscribers. One solution would be to route to a dedicated EMS Server for that consumer. Message that do not meet the client selector criteria are dropped.

Slow Consumers

Selective Consumers Server Recovery (Server restart with pending messages)

Server Recovery time depends on the number Server Recovery time depends on the number of of pending messages in the queues. durables and number of pending messages in the topics.

1.1.1

Queues or Topics Which to Use? The JMS API standard makes clear distinctions between Queues and Topics. Changing between a Queue or a Topic implementation generally involves code change and/or application re-deployment. This means that you need to understand at design time whether a Queue or a Topic will be used for a given destination. The case goes beyond whether the message distribution is one-to-one or one-to-many because there are other differences between the two destination types (as the table above illustrates). Fundamentally the choice must be made on the requirements for message distribution and there is no one size fits all answer. Most integration solutions have a number of software components on any given message path e.g. between an application server through a technical adapter then through a semantic adapter. From the point of view of an external service consumer, these messages are not accessible and hence are internal messages (i.e. internal to the solution or the service implementation) [1]. These internal messages are usually best implemented as Queues since they often are point-to-point and not subject to additional unanticipated listeners in future. Public interfaces such as the JMS destinations for Service providers or consumers (in an SOA) often need to support one-to-many semantics of Topics. They also often need to be routed through multiple EMS servers across a geographically dispersed organization. However, Service providers may also need to support faulttolerant or load-balancing functionality.
Semantic differences between Topics and Queues require consideration during the application design. Programming to generic destinations is impractical in all but the simplest use-cases.

In any case, the semantic differences between Queues and Topics listed in the table above indicate that the behaviour differences between Queues and Topics require specific design decisions in all but the simplest usecases. So programming to generic destinations is often impractical.