DropboxMQ: Home

1.0 - Fully JMS Compliant Sunday, Oct 25, 2009

The functionality is 100% there and this release has been in production at my day job for several months now. Sorry for holding it back but life has its demands. Not a lot changed between 0.9 and 1.0. Looking at README.txt nothing really stands out.

What is DropboxMQ?

How well does your JMS recover?

Here is the scenerio: You have a JMS application that reads a message, does some work, stores something in a database, and finally sends a reply message. Say the database crashed about two hours ago and the application has burned through hundreds of messages, erroring out on each message. So you fix the database and everything is running fine again. But how do you recover all of those lost messages?

The answer depends largely on which JMS provider you use. With DropboxMQ, you simply cd to appropriate dropbox's error directory and

`mv * ../target/`

Done!

Welcome to DropboxMQ! A 'dropbox' is a common way to share information electronically by 'dropping' files into a shared folder in one process (the message producer) then reading the files from the same shared folder in another process (the message consumer). DropboxMQ formalizes this communication and wraps it in the Java Message Service (JMS) API.

Most if not all file systems, shared and local, move files from directory to directory in an 'atomic' operation; the move either entirely succeeds or entirely fails but partial success or failure is not possible. DropboxMQ uses this 'atomicity' to resolve contention between multiple consumers. In a dropbox directory, each message is contained in a separate file. Multiple message consumers can be attempting to consume a message at the same moment in time but because each consumer first attempts to move the file, only one consumer will succeed in consuming the message.

Dropboxes are cross-platform and language independent. At the company where I work, we have applications that interact with dropboxes running on Solaris, IRIX and Linux written in Java, C and a variety of shell languages. In fact, directly from the command line, messages can be sent to or removed from a destination without any adverse effects on other applications.

Dropboxes are as scalable and fault tolerant as the file system on which they are stored. My company uses a NetApp with a fully-redundant, active-active controller configuration. We are passing hundreds of thousands of messages per day between dozens of servers while using less than 5% of the NetApp's bandwidth.

Previous News:

0.9 - 99.9 % Complete Monday, Dec 1, 2008

Only a very few (all minor) issues need to be addressed before we get to 1.0. Here are the release notes for 0.9:

JCA and XA complete
Selector based routing (was defer mechanism based on JMSType in 0.8)
Read locks (both global and per destination) to stop consumers
Write locks to slow or stop producers
Message selector support for LIKE, message selector implementation complete
Consumer can delete expired messages with deleteExpiredMessages configuration
Consumer can bypass expired checking with consumeExpiredMessages configuration

0.8 - The devil is in the details Sunday, Sep 2, 2008

Looking at previous posts, XA is still at 90%, JCA is still nearly complete and message selectors still don't support LIKE, but much progress has still been made. Hopefully we can avoid having the last 10% taking 90% of the time. What is in this release is a much more correct JCA and a very solid core.

There have been a couple of interim builds that were not widely published. 0.7 is in production currently at my day job and this 0.8 release is slated to go in mid-October.

0.5 - Interim build Sunday, Jan 13, 2008

This is an interim build to tag a release that will be going into production at my day job. There has been considerable work since 0.4 but unfortunately none of it is 100%. The most egregious bug is in Session.rollback() for which I already have a fix but like I said I need to tag this as is. XA is 90% complete but doesn't recover transactions when there is a system outage. JCA is nearly complete but doesn't work with XA. Message selectors don't currently support the LIKE identifier.

I obviously haven't been twiddling my thumbs but it hard to believe that it's been over a 1 1/2 years since the last release. 0.6 should be just a few days past 0.5. 1.0 will happen when all of the issues mentioned above are 100% which feels very close.

0.4 - Today's Topic: Pub-Sub is now available Monday, Jul 17, 2006

Until now dropboxes were typically used in a point-to-point messaging domain. DropboxMQ 0.4 changes that while maintaining the same basic architecture of previous versions. We have also added some administrative tools and freshened up the documentation.

I'm thinking the next release will contain support for distributed transactions which sounds much more interesting than message selectors.

Enjoy and let me know what you think.

0.3 - Docs, Message types and a `QueueBrowser` Saturday, March 4, 2006

The primary goal of this release was to tie up loose ends and greatly reduce the number of filtered-out JMSCTS tests. The basic architecture remains unchanged but we now support all JMS message types and the QueueBrowser interface. And the documentation should actually make this thing useable now.

Onward to pub-sub!

0.2 - All JMSCTS Point-to-Point Tests Pass Saturday, January 14, 2006

DropboxMQ is now in full compliance with all JMSCTS point-to-point tests. The exact list of filtered out tests can be seen here. Now the prioritized list of new features is as follows:

QueueBrowser implementation
Support for all message types (only Message and TextMessage are currently supported)
Pub-sub messaging
Message selectors
XA transactions

0.1 - Functional JMS from a 36 K jar! Sunday, October 23, 2005

DropboxMQ is far from complete, but it is already functional with several JMS applications. This release only supports point-to-point message model (pub/sub will be supported in a later release).