¤ Automatic performance scaling ¤ Scaling through configuration changes in the exchange bindings (splitting queues in topic exchanges (later in AMQP part)) ¤ Various message patterns: ¤ Request/Reply (RPC) ¤ Fire and forget ¤ Publish/Subscribe ¤ Auto-retry behavior (timeouts and transaction)
as: ¤ Is the receiver up? ¤ Could the receiver consume the message? ¤ Failure of delivery ¤ Instead of thinking about interface of function calls, think about the data and the flow of data ¤ Handling failure of response gracefully (timeouts) which doesn’t overload a system
same set of queues to handle more requests ¤ Multiple requesters won’t bring down your server (they have to bring down your broker, which is unlikely) ¤ No configuration files on the requesters side (Zookeeper can solve this, but it’s another system to maintain)
message to all the numbers with best effort ¤ Original approach: ¤ Insert into DB ¤ Cron job to read from DB and send message ¤ All using JTA!! (dreadful, but required as the accounts and the messages are on different DBs) ¤ Doesn’t scale well (max 500 messages, JTA timeout at 60s)
to deduct the same account come at the same time. 2/ Multiple similar DB insertions are not batched. Solved with scheduled tasks by Dead-letter exchanges
using ActiveMQ (JMS) with scheduled delay to check if a message was delivered ¤ The scheduled delay was a fixed amount ¤ Migration to ActiveMQ is easy with dead-letter exchanges ¤ Using Spring, both ActiveMQ and RabbitMQ listeners are POJOs (specify the handling method in the configuration) ¤ Mostly configuration changes for listeners and type changes for senders.
topic, header, (system) 2 models: 1-to-1 and pub/sub Binary data 5 different data types Clients send to exchanges, exchanges forward to queues Clients send directly to queues or topics Language agnostic Only support JVM languages Define a wire-level protocol standard Define a set of APIs
+ Slaves Dynamic clustering: Nodes can join/leave None that I know of Full replication (mirrored queues) or full visibility (clustering) Networks of brokers