Hi Carl, > > 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.
Ok... What if there are multiple store plugins loaded? Is it reasonable to document "don't do that" to avoid this potential issue? > > 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. > > > 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. Yes, we can, as long as there's a way to deal with the possibility of multiple store plug-ins being loaded. > > #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 I'm not sure I follow this... > 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. Ok, good point. I assumed that most sites would want durable. > 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. Ok, #3 is out. > > #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. How so? > 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. Right! I agree - and I want to be able to reuse as much of this code as possible for Windows, so getting a clean line of separation/interface to the underlying store is important to separate them. -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
