I’ve just checked in a new Thrudb service that I’ve been working on for the past few days called Thruqueue. I’m sure you can guess by the name that it’s yet another message queue service. But this one has some great features that I think makes it stand out.

No hard limits - Create as many queues you like, send messages as large as you like, send as many messages as you like.

Persistant queues - Under the hood Thruqueue is exploiting Thrift’s powerful redo logging capabilities so queues are really managed logs, one log per queue. At specified intervals the logs are pruned to maintain disk space, this means the memory profile of thruqueue stays small since only a few items from each queue lives in memory at any given time.

Unique Queues - I’ve also added the ability to create unique queues which essentially means no duplicate messages can exist in the queue at once.

Fast! - I’ve done almost no performance optimization but my initial tests look very promising in 1 second I can write then read ~1200 small messages.

Thrift - Want a client in your favorite language? just run: thrift -favlanguage Thruqueue.thrift

Whats missing:

Replication - Do you really need this? I could hook this puppy up to spread but I’m not sure I see the benifit.

Redundancy - Throxy? TBD

I know that there are certainly a lot of message queues out there but all of then are either non-persistant, cost money, require an underlying rdbms, or cost money. Let me know what you think.

This entry was posted on Friday, December 28th, 2007 at 8:12 pm and is filed under thrudb, coding, thrift. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.