Log in

No account? Create an account

Wed, Oct. 24th, 2007, 04:35 pm
Now that it's raining more than ever

I've been thinking about Pub/Sub messaging systems for a while now.

ActiveMQ and I are no longer friends. I dislike going into details but things had been simmering for a while, the odd snide remark, a bit of passive aggressiveness tinged with disappointment until one day something small turned into a big argument and, well, let's just say that things were said. "Buggy, no good piece of crap" springs to mind now that I come to think of it.

Yesterday, some other 6Aers and I had lunch with Blaine Cook and some of the Twitter crew to talk to them about Starling, their new high performance messaging system based around Memcache and to swap war stories. Hark at me! Hanging around with the hip SOMA kids! It's like the time the cool kids at school stopped wedgieing me and let me hang around with them as long as I took the blame for torching that car. Ah, good times.

Anyway, it's an interesting approach - obviously not suitable as a drop in replacement for TibCo's Rendezvous or whatever but definitely useful in certain situations. One limitation is that there are only Queues i.e only one consumer can grab a message. However I think it should be possible to hack things to allow Topics i.e multiple

One idea was

  1. Designate a certain key a Topic somehow, possibly by prefixing the key with "topic://" or similar.

  2. Every client that subscribes to this Topic is noted by the system.

  3. Messages are posted just as normal.

  4. Then a special client listens to the Queue and then duplicates N copies of the message (where N is the number of subscribed clients) and inserts the copies in a queue for each client.

  5. Each client then polls their individual queue as normal.

This is conceptually very easy but has the disadvantage of needing N copies of the message which could be a waste of memory.

However it would probably also be possible to only have 1 copy of the message but keep a ref count. Hell, Memcache even has atomic dec() and inc() operators - Que Convenient!.

Thu, Oct. 25th, 2007 07:31 am (UTC)
cudddly: memcached

I'm still not sure memcached is the way to do this. It's a memory cache, see. It's not a store for whatever funky data structure you happen to have thought up. Something more interesting would be a properly distributed pubsubthingy. Anyway, your main problem is making sure things are never dropped.

Thu, Oct. 25th, 2007 06:59 pm (UTC)
deflatermouse: Re: memcached

First, a disclaimer. I actually wrote this post to test something so it's a bit more hurried than I wanted it to be. For a start it doesn't mention the work that Jesse and Audrey did on IPC::PubSub which has many of the same ideas.

So, in general, I agree with you. Shoehorning something onto something else generally leads to badness (see also: Lotus Notes, Outlook) as the metaphors start to grate against each other.

On the other hand if you flip your argument and think of Memcached as a distributed storage and drop-box architecture that happens to work as a cache then things look a little different. It's possible that for a 70% or 80% case then something that almost looks like a Pub/Sub system would work well enough to be good.

On the other, other hand, as you point out - it lacks several important features such as guaranteed delivery. When I was thinking about writing my own Pub/Sub thing in Erlang I discovered OpenAMQ which was originally written in Erlang. It looks quite shiny although it doesn't do persistent messaging.

I've spent the last 2 weeks bashing my head up against transactionality, partitioning and distributed race conditions so I'm painfully aware of how difficult these things are. At nights I cry a little.

Make the pain go away.