Friday, January 9, 2009

Message Selectors and ActiveMQ

Having just completed a consultancy on FUSE Message Broker (Enterprise Apache ActiveMQ), I just thought I'd write some notes about the use of message selectors in JMS, and, in particular, how FUSE Message Broker implements them.

Message selectors are easy to use, allowing a consumer to specify a filter, using an SQL-like syntax, describing the messages of interest. This filter, example "customerStatus = 'Gold'" instructs the broker to only send messages to the consumer that have a customerStatus header equal to "Gold".

While message selectors are attractive and conceptually very nice, they do place a burden on the broker: consider the case where you have a large number of consumers, say n, on a queue: for each message the broker must evaluate between 1 and n message selectors before delivering the message. In the case of topic, all n message selectors will have to be evaluated for each message. Ouch: that's a lot of work to be putting on the broker, particularly if you're looking for high-throughput.

But apart from this, ActiveMQ's memory paging architecture has an optimisation that can flummox you when using message selectors. When messages are sent persistently, ActiveMQ will only page a portion of the messages in memory, but leave the rest on disk. This is very reasonable: however, one side effect of this is that selectors are only evaluated on those messages in memory, not those in the store. So, if your page size is 100, and you have 100 messages for which there is no current matching consumer, you end up with a "hung" queue. For example, consider the case where you have two consumers, selecting on "color = 'red'" and "color = 'blue'" respectively - here, "color" is a custom JMS message header. Let's say that the first (red) consumer is currently not in operation, and we receive 100 messages for red. Blue is waiting, waiting, waiting, but does not get any messages as there are no matching ones present. Now, we get message 101 - a nice blue message. However, our selectors are only matching against the first 100 messages (all red!) so blue still hangs, waiting, despite the fact that there's a perfectly matching message.

That example is perhaps contrived, but it does demonstrate a potential "hanging consumer" problem. For me though it's a natural side-effect of wanting to limit the broker-side overhead of having to evaluate message selectors. You can of course modify the page size to reduce the chance of the problem happening, but you're just reducing the probability of the lock happening.

My customer had come up with a conceptually elegant callback design, whereby as messages are forwarded through a server, a consumer is created (for each message) to listen on a queue for a subsequent response, using a unique message identifier within a message selector. While conceptually nice as a design, the overhead (in terms of dynamic consumer creation and message selector processing) just isn't worth it. We proposed an alternative architecture using named queues and a fixed pool of response consumers that's going to work way, way better.

Thursday, January 8, 2009

Looking forward to ApacheCon Europe 2009

This year I'm thrilled to be doing a number of talks at ApacheCon Europe 2009, and a full day-long tutorial on building web and REST services with Apache CXF (FUSE Service Framework). Abstracts below - see you there!

Talk: Tales from the Front Line: how ServiceMix, ActiveMQ & CXF are being used to solve real problems. In this session we discuss how application integration and middleware-focussed Apache projects - like ServiceMix, ActiveMQ, Camel & CXF - are being used to build innovative solutions that add real value to organizations in health-care, government, airline-solutions and finance. For each use-case, we discuss both logical and deployment architecture concerns. We also discuss the motives for adopting open-source in these solutions, and why these Apache projects where chosen above other open source alternatives.

Talk: Adopting Open Source in the Enterprise.
For some organizations, the decision to adopt open source software
is not taken lightly, and, once made, can require significant shifts
in thinking and organization culture. This session discusses the
issues organizations face when strategically adopting open source,
including how to select open source projects, how to match open source
involvement & contribution with corporate strategy, how to select &
manage professional open source software vendors, what needs to be
done in terms of licensing and legal, and what kind of infrastructure
you need to support your open source strategy.

Tutorial (full day): Apache CXF - Developing and Deploying Open Source SOA Endpoints
This one-day tutorial will show how to design, build and deploy RESTful and Web-based web services using Apache CXF. The session will cover code-first and WSDL first services design for JAX-WS, and show how to use JAX-RS for restful services. We'll show how to swap different transports (HTTP, JMS) with different payload types (XML, SOAP, JSON). And, we'll show how CXF's support for JavaScript can be used to create client- and serverside components for AJAX applications. This workshop will combine a mix of lectures, whiteboarding, and hands-on exercise sessions.