qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Broadstone <mbroa...@gmail.com>
Subject Re: custom store plugin for qpidd
Date Mon, 15 Aug 2016 13:58:32 GMT
On Mon, Aug 15, 2016 at 9:46 AM, Andrew Stitcher <astitcher@redhat.com>
wrote:

> On Sat, 2016-08-13 at 11:49 -0400, Matt Broadstone wrote:
> > ...
> > > However this can only happen if the linear/legacy stores are
> > > modified
> > > to use the API it exposes, as otherwise there would be two store
> > > plugins vying for the exclusive right to be a store using that
> > > plugin
> > > API.
> > >
> > >
> > I actually don't think this is correct. I believe the linear/legacy
> > stores
> > don't use the store plugin (or its interfaces) at all.
>
> I think you misunderstood what I meant - the linear/legacy store
> currently use the same exclusive API that the store plugin does, and so
> they cannot be loaded into the qpidd process at the same time as any
> other store (even each other). To change this (which strikes me as a
> good plan) they will need to be changed to use the store plugin API not
> the lower level exclusive API.
>
> The store plugin cannot be built into the qpidd executable until this
> happens or those plugin stores would never be able to be loaded as
> their exclusive API would already be taken by another piece of code.
>
> If I remember correctly the current Linux plugins are written as a thin
> API layer on top of the real journalling code so changing the way they
> interface to qpidd might not be too difficult (but someone would need
> to actually do it).
>
> Andrew
>
>
Ah yes, this is my understanding as well sorry for the confusion.

It's also my understanding that, in general, there's a requirement than any
given store plugin be loaded one at a time (though you're correct that it
seems the two windows plugins may be loaded simultaneously). I think what
I'm really getting at here is if there is any downside to converting the
store plugin to a shared library, rather than a cmake module, and linking
each plugin that currently requires it directly to it - rather than passing
arguments like: `--load-module store --load-module
my-custom-store-plugin`?  The existing windows mssql plugins seem to depend
on undefined behavior in cmake, in that a `MODULE` target is built exactly
like a `SHARED` target.

That's what I've done in my local code and it seems to work just fine, just
wanted to make sure I wasn't inadvertently breaking the windows path.
Unfortunately, I don't think I'll have the time to take over the store
plugin refactor you're discussing, but I do agree that it sounds like the
right way to go in terms of consistency and helping future implementors.

Matt


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message