On 07/28/2009 10:24 AM, Carl Trieloff wrote:
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.
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.
#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.
I like choice 1, except I think the appropriate plugin should be
specified in the configuration, i.e. /etc/qpidd.conf or the analogous
windows file. If you're using a database like Oracle or SQLServer
you'll have to specify username/password, or depend or OS user
authentication.
//Bill
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
