On Fri, 2009-06-12 at 19:59 +0100, John R O'Hara wrote: > Hi Dave > > CLFS is neat and probably blisteringly fast on Windows.
Looking at the docs CLFS seems to be supported only since Windows 2003 which I think would exclude the many XP systems out there, so that might not be so good. > > I'm not aware of the current design of the C++ Qpid storage subsystem and how > much smarts it requires (in particular does it need/supply indices for > selectors on persistent messages queued to disk?). > If its just a linear log then using CLFS would be neat in the Windows build; > but something else should be swapped in if it's not there and being built > somewhere else. To my (somewhat limited) understanding there are 2 parts of the c++ qpid storage subsystem (Kim would be able to fill in more details): 1. Journal files per queue, (Effectively a linear log) 2. Persistent wiring. Presently the bulk of the code is in 1. which is a self contained layer using the Linux asynchronous disk io (aio_) calls to efficiently drive disks. I think this code has no external dependencies besides qpid itself. This is the truly performance critical part of the store. The second part is much less code, but it uses the sleepy cat bdb code as a backing store. It would certainly be possible to eliminate the bdb dependency entirely, it's just a SMOP. > > That something else must have these two characteristics: > 1) Be ASL compatible so it can ship with the source distro and users have a > simple out-of-box experience > 2) Be very reliable > > SQLlite is one of the few things that ticks both boxes on C/C++. Its TX > handling looks suitably paranoid, and a simple message table with appended > inserts could serve as a functional log solution. I agree that Sqlite would be a good match for a db backend. Also note, it's widely available on many different platforms (pure ANSI C); the code is small (in the 100k-300k region); it's pretty performant; it would supports external tools managing the store given it supports a pretty complete SQL (despite the 'lite') > > So I suggest that the storage subsystem defaults to SQLlite by default and > picks up any available "better" option during the build process - which would > be CLFS on Windows, since its part of the OS and > BDB/TokyoCabinet/QDBM/SQLserver/whatever where available. I think that the problem here is that there will be limited desire from the implementors to spend the effort to provide a storage layer that isn't adequately efficient on their platform just for the sake of a portability. SoC project anyone (I guess that'd be next year!) Andrew --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
