I've had a chance to have a brief look at the MRG code and have more thoughts on this...
> Steve Huston wrote: > > I'm working on an Apache-licensed persistence plug-in for > the qpid C++ > > broker. Microsoft is funding this work, so naturally it's primary > > target is Windows. However, Microsoft is also supportive of > the notion > > that the whole community and user base would benefit from a > > persistence module operating on Linux, Solaris, et al and > is therefore > > supportive of a secondary goal for this work to end up with > a portable > > plug-in that can accommodate multiple database/backing stores under > > common persistence/recovery code. > > > > At a high level, there are basically three ways to do this... > > > > 1. Combine the portable and store-specific code into > plug-ins, one per > > store. Hope that there's only one there when the broker starts. > > > > I like this option. I previously came around to this as well, but have reconsidered. See below. > > 2. Build the persistence module as one plug-in and the stores are > > separate "sub plug-ins" that plug into the persistence plug-in. > > > > 3. If the persistence plugin is always there, it could be > changed from > > a plugin to a linked-into the broker and the backend stores are the > > only pluggable pieces. > > > > > This is not the way to go in my view. #3 was earlier discounted because it brings in the weight of the persistence code even when it's not wanted, which could be often. So forget that. However, I'm reconsidering #2 to ensure that there's a clean split between Apache code and non-Apache code without making a headache trying to build mixed code. If, for example, the general store plugin code is built, and the existing BDB code (for example, reworked to fit into the general store plugin architecture) is wanted, that would involve someone needing to check out qpid svn, get the BDB-based code from somewhere, then edit the qpid cmake description to know it can pick up the BDB code from somewhere. That's the step that's headache prone. Similar headaches from other private back ends - the supposedly locked-down qpid code needs to be edited to build with the specialized back end... Yuck. If the back ends are built and maintained completely separately there's no confusion about the build, source repos, etc. Build the back end however you want, from wherever you want, and drop the module in place for the broker to load. This would also force a clean interface since it needs to be invoked through a class interface known from the general store plugin side. Thoughts? Thanks, -Steve > > The way #1 works is pretty straight-forward except for the > case where > > there are multiple plug-ins (for example, one for BDB-aio > and one for > > MySQL or Oracle - some sites are very insistent on where > their data is > > stored). The last one initialized wins? > > > > we can get code re-use and build it more than one way if needed. > > > #3 may be the simpler way to go, but is more of a departure from > > today. What do people think of this? > > > > I would not support this. Reason is that it avoids forcing > clean lines > of interfaces > and makes the broker heavy for cases where features are not > used. Many > people don't > care about durability and should not have to carry the > dependencies for it. > > Much in the same way we have modules for SSL, RDMA, Clustering, XML, > replication, > etc... I am not in favour of 3 and would not support not having it > runtime loadable. > > > #2 is the way I think (at this point) it should work. Much of this > > would apply to #3 as well. Basically, this would be: > > > > - A class MessageStorePlugin is the main plug-in interface point. In > > addition to inheriting from qpid::Plugin it would also inherit from > > Plugin::Target > > > > - MessageStorePlugin has a "--store=<name>" option to select the > > backend store. There would have to be a default as well as a way to > > remember which store was used if the broker is recovering. > The <name> > > part is a name specified by the sub-plugins. Since the names are not > > all known before option parsing there's no way to validate it during > > parsing - have to wait until earlyInitialize() > > > > - The available store backend plugins are also loaded at > broker start > > along with all the other plugins. As a plugin, they also > provide their > > particular options for parsing. The difference is that when > > [early]Initialize() is called these don't respond to Broker Targets, > > they respond to MessageStorePlugin Targets. > > > > - During earlyInitialize() the MessageStorePlugin can itself call > > earlyInitAll, supplying itself as the Target. The store backend > > plugins recognize the MessageStorePlugin target and call a method on > > it to supply identifying information like a name (one of > which has to > > match the --store=<name> name) and a pointer/reference. > Once this step > > is done, the MessageStorePlugin can make some association with the > > selected store backend and be ready for broker restore. > > > > > > That's it for now... Once discussion slows or comes to > concensus I'll > > write something up for the wiki to summarize the resultant approach. > > > > option 2 can work, but my concern is that it might get too > bloated. For > those on the list, I am looking > into getting the C++ async store contributed to apache on a JIRA. The > issue I am working through is > it uses BDB in a few places. This would need to be replaced with non > -BDB impl to be able to be > committed to Apache. I need to get a mail to Apache legal on > this topic > still to close this off. > > The update of this code to non BDB could be reused, however I > would want > the updated version to not > bring in a trail of dependencies. > > Carl. > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
