Apache Apollo 1.0 Released!
Congrats to @hiramchirino and the whole AMQ team!
Why developers should be force-fed state machines
When applicable they are incredibly powerful.
Queueing MongoDB using MongoDB
The solution is as interesting as the problem.
Caching and Processing 2TB Mozilla Crash Reports in memory with Hazelcast
Awesome use of hazlecast, essentially using a distributed hashmap to act as a partitioned queue.
Kafka
Fantastic read on Linkedin’s message bus design choices.
A Retrospective on SEDA
A great retrospective by the SEDA paper author. The “what we got wrong” section is particularly interesting and certainly crosses over with HawtDispatch/Grand Central Dispatch
Python messaging: ActiveMQ and RabbitMQ
A simple but but comparison of ActiveMQ and RabbitMQ. This, combined with Reddit’s experience makes me pretty wary of using RabbitMQ.
Message Passing Leads to Better Scalability in Parallel Systems - Programmer 97-things
After creating a highly scalable and parallel application built on ActiveMQ, I can say this is dead on.
There are a few relatively obvious and well-known strategies for reducing the number of remote inter-process communications per stimulus. One strategy is to apply the principle of parsimony, optimizing the interface between processes so that exactly the right data for the purpose at hand is exchanged with the minimum amount of interaction. Another strategy is to parallelize the inter-process communications where possible, so that the overall response time becomes driven mainly by the longest-latency IPC. A third strategy is to cache the results of previous IPCs, so that future IPCs may be avoided by hitting local cache instead.
— Inter-Process Communication Affects Application Response Time - Programmer 97-thingsSynchronous Request Response with ActiveMQ and Spring
A few months ago I did a deep dive into Efficient Lightweight JMS with Spring and ActiveMQ where I focused on the details for asynchronous sending and receiving of messages. In an ideal world all messaging would be asynchronous. If you need a response then you should set up an asynchronous listener and either have enough state stored in the service or in the message that you can continue processing once the response has been received. However, when ideals lead to complexity, we have to make the decision of how much complexity can we tolerate for the performance we need. Sometimes it just makes more sense to use a synchronous request/response.
