Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Message-ID: <1471272193.3093.20.camel@redhat.com>
Subject: Re: custom store plugin for qpidd
From: Andrew Stitcher <astitcher@redhat.com>
To: users@qpid.apache.org
Date: Mon, 15 Aug 2016 10:43:13 -0400
In-Reply-To: <CAMsD-yA4_a693zj4H4ftOAbi2AemrOFZTW3UdkB81sJ9Ln5nLg@mail.gmail.com>
References: 
	<CAMsD-yCH0qVPrDcMZqbpBt6Q3-O6Nwyd=7WO+uO4RKnit+WB3g@mail.gmail.com>
	 <CAMsD-yDXdLEyOp0v2BgK3_EYN86TFuUn9GunWRpHK5fkLEwRnQ@mail.gmail.com>
	 <1471023103.3446.27.camel@redhat.com>
	 <CAMsD-yD70s37h86647bYHws5Laa2BM=gJ8mxosuxVSmdPg56mA@mail.gmail.com>
	 <1471268804.3093.7.camel@redhat.com>
	 <CAMsD-yA4_a693zj4H4ftOAbi2AemrOFZTW3UdkB81sJ9Ln5nLg@mail.gmail.com>
Organization: Red Hat Inc
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
archived-at: Mon, 15 Aug 2016 14:43:20 -0000

On Mon, 2016-08-15 at 09:58 -0400, Matt Broadstone wrote:
> ...
> 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.

Ah, now this I can answer more authoritatively! (As I'm responsible for
the current qpidd plugin architecture - to the extent it can be called
that at all!)

All plugins can be built intop qpidd from the functionality POV
(allowing for some exceptions like only allowing one store plugin).
This is because there is no plugin API as such. All plugin API
registration currently occurs as a side effect of static global
initialisation.

It just so happens that on all platforms we care about loading a shared
object/DLL will run the static initialisation code for the loaded code.

Now if the same piece of code is just linked statically into the
executation the static initialisation just gets run when the
executabtle starts up.

From this POV there is no difference between linking a DLL/shared
library to the executable and linkng the code directly into the
executable - the plugin module just gets initialised at executable
start up.

If you are going down the route of shared library for the store plugin
in your configuration then you may as well just add it to the
executable directly (or through a static library) there's no real point
in using a shared library.

However I've refrained from doing this simply because you can only do
this on Windows as on Linux you can't do this and still use the
linear/legacy stores as I've already mentioned.

So I'd advise to keep the store plugin as it currently is until the
Linux stores are converted.

Incidentally there should be no real need outside of specific test
scenarios to have --load-module arguments as the will all be loaded by
default (as long as they are in the correct place, and if not then --
load-module won't work either!). This of course is screwed by having
multiple stores present on Linux.

Andrew


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