CouchDB
  1. CouchDB
  2. COUCHDB-1046

support load of external erlang modules in couchdb.

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Database Core
    • Labels:
      None
    • Skill Level:
      Regular Contributors Level (Easy to Medium)

      Description

      If you want to add external modules in CouchDB and load them , you need to set the ERL_FLAGS environnement variable to the path of a module.

      The attached patch allows couchdb to load plugins from plugin key in couchdb section. It add needed path to the code path, so the vm can find modules.

      ex:
      [couchdb]
      plugins = plugin1, plugin2

      Each plugin can have its own section where it set the binaries patch, eventually if a service need to be added to the supervision you can set the module and function to load like in daemon section and tel if it's a supervisor or simple service.

      It also allows couchdb to load a plugin service (gen_server or such) to the supervision. You can choose if the service is a simple daemon or a supervisor.

      ex:
      [plugin1]
      code_path = /path/to/plugin1/ebin
      daemon =

      {module, function, [Args]}

      supervisor = false

      Let me know what you think about it. This patch is really useful here and allows me to dynamically load modules I want. Also it eases the integration of external module. For ex I can load my couchapp_ng modules with this lines in local.ini :

      [couchdb]
      plugins = couchapp-ng

      [couchapp-ng]
      code_path=/Users/benoitc/work/couchapp_ng/ebin
      daemon =

      {couchapp_ng_routes, start_link, []}

      [httpd_design_handlers]
      _app =

      {couchapp_ng_httpd, handle_app_req}

      [couchapp_ng_handlers]
      rewrite =

      {couchapp_ng_handlers, rewrite_handler}

      proxy =

      {couchapp_ng_handlers, proxy_handler}

      and can do the same with geocouch etc. Tested here with these modules.

      1. couchdb-plugins-01.patch
        3 kB
        Benoit Chesneau
      2. couchdb-plugins-02.patch
        4 kB
        Benoit Chesneau
      3. couchdb-plugins-003.patch
        7 kB
        Benoit Chesneau
      4. couchdb-plugins-004.patch
        7 kB
        Benoit Chesneau
      5. couchdb-plugins-005.patch
        8 kB
        Benoit Chesneau

        Activity

        Hide
        Jan Lehnardt added a comment -

        Bump to 1.3.x.

        Show
        Jan Lehnardt added a comment - Bump to 1.3.x.
        Hide
        Randall Leeds added a comment -

        I think Paul means COUCHDB-1012

        Show
        Randall Leeds added a comment - I think Paul means COUCHDB-1012
        Hide
        Paul Joseph Davis added a comment - - edited

        I'm not a big fan of this patch. I think we should focus on finishing up COUCHDB-1012 and then people will be able to install their plugins into Couch's ERL_LIBS directory. Once that exists people can go hog wild on whatever it is they want to do.

        [edit: Thanks for the catch Randall]

        Show
        Paul Joseph Davis added a comment - - edited I'm not a big fan of this patch. I think we should focus on finishing up COUCHDB-1012 and then people will be able to install their plugins into Couch's ERL_LIBS directory. Once that exists people can go hog wild on whatever it is they want to do. [edit: Thanks for the catch Randall]
        Hide
        Benoit Chesneau added a comment -

        Is there any more work to do to have it in trunk? Any feedback is appreciated.

        Show
        Benoit Chesneau added a comment - Is there any more work to do to have it in trunk? Any feedback is appreciated.
        Hide
        Benoit Chesneau added a comment -

        last version of the patch in sync with the github repo.

        Show
        Benoit Chesneau added a comment - last version of the patch in sync with the github repo.
        Hide
        Benoit Chesneau added a comment -

        Totally!

        I think we can also create a rebar template for couchdb plugins.

        This template would install a couchdb plugin directly putting deps in plugin dir directly and removing useless deps.
        We could also while we are here make rebar abble to find the couchdb includes files, so we don't need to create a rebar.config template.

        Show
        Benoit Chesneau added a comment - Totally! I think we can also create a rebar template for couchdb plugins. This template would install a couchdb plugin directly putting deps in plugin dir directly and removing useless deps. We could also while we are here make rebar abble to find the couchdb includes files, so we don't need to create a rebar.config template.
        Hide
        Randall Leeds added a comment -

        I would love for plugin developers to start using something like https://github.com/agner/agner
        If you point DESTDIR at the couchdb plugin dir, developers shouldn't need to package deps with their plugins and plugins could share deps.
        There's a beautiful way forward hidden here somewhere, I think...

        Show
        Randall Leeds added a comment - I would love for plugin developers to start using something like https://github.com/agner/agner If you point DESTDIR at the couchdb plugin dir, developers shouldn't need to package deps with their plugins and plugins could share deps. There's a beautiful way forward hidden here somewhere, I think...
        Hide
        Benoit Chesneau added a comment -

        Updated the repo:

        https://github.com/benoitc/couchdb/commit/1f419c87cbbd4c2c77bc772c4037a9fbe4b65ef3

        • only load first level app, deps need to be installed in plugin dir
        • don't accept/load applications that are already loaded by couchdb (its
          dependencies)
        • don't uses application env to save temporary data. use an ets for
          that.

        I think we should just trust plugins are loaded with needed deps. If one is missing couchdb will hangs with a "beautiful" erlang trace with an "undef" message.

        the don't is enough imo

        I agree.

        Show
        Benoit Chesneau added a comment - Updated the repo: https://github.com/benoitc/couchdb/commit/1f419c87cbbd4c2c77bc772c4037a9fbe4b65ef3 only load first level app, deps need to be installed in plugin dir don't accept/load applications that are already loaded by couchdb (its dependencies) don't uses application env to save temporary data. use an ets for that. I think we should just trust plugins are loaded with needed deps. If one is missing couchdb will hangs with a "beautiful" erlang trace with an "undef" message. the don't is enough imo I agree.
        Hide
        Paul Joseph Davis added a comment -

        That sounds closer to what I was thinking yeah.

        I'm not entirely sure how we'd be able to test what the app depends on before loading it. Do we have to load up the app file and trust the deps are correct?

        I'm not entirely certain on how to handle people moving stuff around on the filesystem while the code is loaded into the VM. Perhaps just telling people "don't" is enough?

        Not sure about removing install things via Makefile, but I would agree the scope is probably outside the level of CouchDB.

        Show
        Paul Joseph Davis added a comment - That sounds closer to what I was thinking yeah. I'm not entirely sure how we'd be able to test what the app depends on before loading it. Do we have to load up the app file and trust the deps are correct? I'm not entirely certain on how to handle people moving stuff around on the filesystem while the code is loaded into the VM. Perhaps just telling people "don't" is enough? Not sure about removing install things via Makefile, but I would agree the scope is probably outside the level of CouchDB.
        Hide
        Benoit Chesneau added a comment - - edited

        Thinking more about it:

        • We could indeed just manage first level of app, and remove the deps folder. The main advantage I see is to force the dev to pay attention to the dependencies he uses. It also solve the pb of versionning betweens deps. It also solve the pb of nifs but I''m not sure what you mean with this one.
        • We need to test if the dev doesn't install apps that conflict with CouchDB deps (mochiweb, ibrowse, erlang_oauth)
        • Clean message when a dev remove an app. Maybe we could provide a way to unload a module from the web.
        • About the installation of a different version of the module I think we should let the devs to remove it via his makefile. I'm thinking to provide a plugin template for that + best practices.
        Show
        Benoit Chesneau added a comment - - edited Thinking more about it: We could indeed just manage first level of app, and remove the deps folder. The main advantage I see is to force the dev to pay attention to the dependencies he uses. It also solve the pb of versionning betweens deps. It also solve the pb of nifs but I''m not sure what you mean with this one. We need to test if the dev doesn't install apps that conflict with CouchDB deps (mochiweb, ibrowse, erlang_oauth) Clean message when a dev remove an app. Maybe we could provide a way to unload a module from the web. About the installation of a different version of the module I think we should let the devs to remove it via his makefile. I'm thinking to provide a plugin template for that + best practices.
        Hide
        Benoit Chesneau added a comment -

        On Thu, Jan 27, 2011 at 10:46 PM, Paul Joseph Davis (JIRA)
        > What happens when two plugins depend on the same erlang app?
        > What happens when two plugins depend on different versions of the same app?
        > What happens when two plugins depend on the same version, and
        after both are loaded one of the two disappears?
        > What happens when its more than two?
        > What happens to NIF resources even if its the same version?
        > Is there a way for plugins to know that they don't need to include
        deps that are included in CouchDB? (Thinking mochijson here)

        application with same name are loaded only once.

        why do we care about that ? It will create an error, the dev will
        solve it or no.

        application with same name are loaded only once. So that can't happen.
        One thing I forgot though is to add to the loaded apps the couchdb
        apps. I will add that

        plugins are all reloaded. How can that happen if deps are managed per
        plugins ? Not sure to follow

        What do you mean ?

        No, the dev knows.

        > What happens when someone dumps a new plugin into the plugins directory?
        > What happens when someone adds a new version of a plugin to the directory?
        > What happens when someone deletes a loaded plugin?
        > What happens to code loading of modules like gen_server2 when its
        included in many projects? (related to multiple dep versions above).

        what do you mean ? not sure to follow on this one

        He make sure to delete old one ? Or we can check app versioning and
        remove old one. Maybe that's better but even erlang don't manage it so
        well.

        It will create an error. But appart the fact that the error should
        be understandable we can't do much about it. I will had a mean to
        manage error display in this case.

        Since modules are loaded by applications it shouldn't be a problem
        I think. The same happen with rebar maybe we could discuss with the
        author about that.

        Totally agree. It's totally clear for me too that we need something
        enough simple but robust if we want to support a plugin system. On the
        other hand we can't do more than erlang can do

        • benoît
        Show
        Benoit Chesneau added a comment - On Thu, Jan 27, 2011 at 10:46 PM, Paul Joseph Davis (JIRA) > What happens when two plugins depend on the same erlang app? > What happens when two plugins depend on different versions of the same app? > What happens when two plugins depend on the same version, and after both are loaded one of the two disappears? > What happens when its more than two? > What happens to NIF resources even if its the same version? > Is there a way for plugins to know that they don't need to include deps that are included in CouchDB? (Thinking mochijson here) application with same name are loaded only once. why do we care about that ? It will create an error, the dev will solve it or no. application with same name are loaded only once. So that can't happen. One thing I forgot though is to add to the loaded apps the couchdb apps. I will add that plugins are all reloaded. How can that happen if deps are managed per plugins ? Not sure to follow What do you mean ? No, the dev knows. > What happens when someone dumps a new plugin into the plugins directory? > What happens when someone adds a new version of a plugin to the directory? > What happens when someone deletes a loaded plugin? > What happens to code loading of modules like gen_server2 when its included in many projects? (related to multiple dep versions above). what do you mean ? not sure to follow on this one He make sure to delete old one ? Or we can check app versioning and remove old one. Maybe that's better but even erlang don't manage it so well. It will create an error. But appart the fact that the error should be understandable we can't do much about it. I will had a mean to manage error display in this case. Since modules are loaded by applications it shouldn't be a problem I think. The same happen with rebar maybe we could discuss with the author about that. Totally agree. It's totally clear for me too that we need something enough simple but robust if we want to support a plugin system. On the other hand we can't do more than erlang can do benoît
        Hide
        Paul Joseph Davis added a comment -

        What happens when two plugins depend on the same erlang app?
        What happens when two plugins depend on different versions of the same app?
        What happens when two plugins depend on the same version, and after both are loaded one of the two disappears?
        What happens when its more than two?
        What happens to NIF resources even if its the same version?
        Is there a way for plugins to know that they don't need to include deps that are included in CouchDB? (Thinking mochijson here)

        Other questions that come to mind:

        What happens when someone dumps a new plugin into the plugins directory?
        What happens when someone adds a new version of a plugin to the directory?
        What happens when someone deletes a loaded plugin?
        What happens to code loading of modules like gen_server2 when its included in many projects? (related to multiple dep versions above).

        I'd like to be clear that I'm do want to make it super easy to have third party code loaded into CouchDB but I'm very concerned that if we're not careful we're going to walk into a tar pit of horribly complex systems that people are going to expect us to fix/support properly. I'd much rather keep the whole thing as super simple as possible so that we aren't held accountable for all the possible weirdness.

        Show
        Paul Joseph Davis added a comment - What happens when two plugins depend on the same erlang app? What happens when two plugins depend on different versions of the same app? What happens when two plugins depend on the same version, and after both are loaded one of the two disappears? What happens when its more than two? What happens to NIF resources even if its the same version? Is there a way for plugins to know that they don't need to include deps that are included in CouchDB? (Thinking mochijson here) Other questions that come to mind: What happens when someone dumps a new plugin into the plugins directory? What happens when someone adds a new version of a plugin to the directory? What happens when someone deletes a loaded plugin? What happens to code loading of modules like gen_server2 when its included in many projects? (related to multiple dep versions above). I'd like to be clear that I'm do want to make it super easy to have third party code loaded into CouchDB but I'm very concerned that if we're not careful we're going to walk into a tar pit of horribly complex systems that people are going to expect us to fix/support properly. I'd much rather keep the whole thing as super simple as possible so that we aren't held accountable for all the possible weirdness.
        Hide
        Benoit Chesneau added a comment -

        about plugin deps, rabbit mq, put all deps in the plugin repo. Do we really want that ?

        That means that a plugin using emonk, for ex, will have to first install emonk in this repo. On the other hand if we keep current possibility of this patch to load from deps folder I can just use rebar to build and get-deps.

        Show
        Benoit Chesneau added a comment - about plugin deps, rabbit mq, put all deps in the plugin repo. Do we really want that ? That means that a plugin using emonk, for ex, will have to first install emonk in this repo. On the other hand if we keep current possibility of this patch to load from deps folder I can just use rebar to build and get-deps.
        Hide
        Randall Leeds added a comment -

        I take that back. Keep in in the ini. That way people can launch couchdb with a custom .ini chain to get a local plugin dir. Something like a plugin virtualenv is even possible. This is not too different from how the `make dev` target and `./utils/run` work.

        pkg-config can point to the default because that'll make configuration easy and cover the 'normal' case for most system-wide installs.

        Show
        Randall Leeds added a comment - I take that back. Keep in in the ini. That way people can launch couchdb with a custom .ini chain to get a local plugin dir. Something like a plugin virtualenv is even possible. This is not too different from how the `make dev` target and `./utils/run` work. pkg-config can point to the default because that'll make configuration easy and cover the 'normal' case for most system-wide installs.
        Hide
        Randall Leeds added a comment -

        Benoit: I like that last approach (keeping it in a private subdirectory).
        Then we don't need to make our own tool. We can find that with pkg-config because it's not configurable after install.

        Show
        Randall Leeds added a comment - Benoit: I like that last approach (keeping it in a private subdirectory). Then we don't need to make our own tool. We can find that with pkg-config because it's not configurable after install.
        Hide
        Benoit Chesneau added a comment -

        this change :
        https://github.com/benoitc/couchdb/commit/9c7e92d2195ec592ad4fb767ed753cf073ecaee8

        put plugin dir in priv path so we can install plugins for a specific couchdb version by default.

        Show
        Benoit Chesneau added a comment - this change : https://github.com/benoitc/couchdb/commit/9c7e92d2195ec592ad4fb767ed753cf073ecaee8 put plugin dir in priv path so we can install plugins for a specific couchdb version by default.
        Hide
        Benoit Chesneau added a comment -

        Installing in $PREFIX/lib/couchdb/erlang/lib would make difficult to detect plugins or are you suggesting $PREFIX/lib/couchdb/erlang/lib/plugins ?

        Which could be better so we make sure plugins are related to one couchbd version.

        • benoît
        • benoit
        Show
        Benoit Chesneau added a comment - Installing in $PREFIX/lib/couchdb/erlang/lib would make difficult to detect plugins or are you suggesting $PREFIX/lib/couchdb/erlang/lib/plugins ? Which could be better so we make sure plugins are related to one couchbd version. benoît benoit
        Hide
        Benoit Chesneau added a comment - - edited

        I've posted the patch on my repo, I will continue the work on it :

        https://github.com/benoitc/couchdb/commit/283a42c76024d1310c999c33e76e421fbdec858d

        For the app env, maybe we we could set a simple ets ? This is mostly what do application:set_env but it may be indeed better.

        For deps I think it's fine here since we only load once an application. I just added that because this the easy way to do coming from rebar. I will have a closer look on this .ez thing though.

        Show
        Benoit Chesneau added a comment - - edited I've posted the patch on my repo, I will continue the work on it : https://github.com/benoitc/couchdb/commit/283a42c76024d1310c999c33e76e421fbdec858d For the app env, maybe we we could set a simple ets ? This is mostly what do application:set_env but it may be indeed better. For deps I think it's fine here since we only load once an application. I just added that because this the easy way to do coming from rebar. I will have a closer look on this .ez thing though.
        Hide
        Paul Joseph Davis added a comment -

        I like this better, but I'm still a bit hesitant on a couple issues.

        First, why do we need a second path to put plugins in? What's the benefit of separating them out of $PREFIX/lib/couchdb/erlang/lib?

        I'm not super thrilled about the manipulations for handling deps. Reading through the code server manpage there are .ez package things that people could use if they want to bundle deps in a single file and not install them separately. Though this is only half an idea cause I haven't considered other bits.

        I like that the plugins are just apps and its becoming a config listener thing for starting and stoping apps in the erlang vm.

        Also I don't think we should abuse set_env here because I could see badness happening if that config section changes too rapidly. Just wrapping it in a small gen_server ought to be enough because its not important if config changes are serialized I think.

        Show
        Paul Joseph Davis added a comment - I like this better, but I'm still a bit hesitant on a couple issues. First, why do we need a second path to put plugins in? What's the benefit of separating them out of $PREFIX/lib/couchdb/erlang/lib? I'm not super thrilled about the manipulations for handling deps. Reading through the code server manpage there are .ez package things that people could use if they want to bundle deps in a single file and not install them separately. Though this is only half an idea cause I haven't considered other bits. I like that the plugins are just apps and its becoming a config listener thing for starting and stoping apps in the erlang vm. Also I don't think we should abuse set_env here because I could see badness happening if that config section changes too rapidly. Just wrapping it in a small gen_server ought to be enough because its not important if config changes are serialized I think.
        Hide
        Benoit Chesneau added a comment -

        right version of the diff. Allows couchdb to load plugins app and their deps installed in

        /plugindir//deps//ebin/*

        Show
        Benoit Chesneau added a comment - right version of the diff. Allows couchdb to load plugins app and their deps installed in /plugindir/ /deps/ /ebin/*
        Hide
        Benoit Chesneau added a comment -

        New version of the patch allowing couchdb to load plugin dependencies in /plugin_dir//deps/ebin/.app .

        Show
        Benoit Chesneau added a comment - New version of the patch allowing couchdb to load plugin dependencies in /plugin_dir/ /deps/ebin/ .app .
        Hide
        Benoit Chesneau added a comment -

        The point of this patches and above is to avoid to have to set an env variables or anything like this when you hav eto load a plugin. In above case, you can eventually get the plugin dir via pkg-config (hopefulyy this patch will land soon) and install it here. Also it would allows to maintain a plugin directory / version.

        Other advantage, during dev i've only to symplink my app to this patch and it works.

        Show
        Benoit Chesneau added a comment - The point of this patches and above is to avoid to have to set an env variables or anything like this when you hav eto load a plugin. In above case, you can eventually get the plugin dir via pkg-config (hopefulyy this patch will land soon) and install it here. Also it would allows to maintain a plugin directory / version. Other advantage, during dev i've only to symplink my app to this patch and it works.
        Hide
        Benoit Chesneau added a comment -

        here is an alternative patch. Rather than reading a code_path and adding it blindly it only take patches installed in a plugin directory. The patch does this:

        • get the pluging dir from ini
        • looks in /plugin_dirs//ebin/.app to get applications to load
        • add aboves directory to the path
        • start applications application:start(app)
        • start app required dependencies by looking in "application" member of the application properties.

        This patch is heavily inspired from rabbitmq, and works a lot better than previous attemps.

        While I was here, I removed the need of an application section, let couchdb loads daemons as usual.

        Tested with couchapp_ng and geocouch.

        Show
        Benoit Chesneau added a comment - here is an alternative patch. Rather than reading a code_path and adding it blindly it only take patches installed in a plugin directory. The patch does this: get the pluging dir from ini looks in /plugin_dirs/ /ebin/ .app to get applications to load add aboves directory to the path start applications application:start(app) start app required dependencies by looking in "application" member of the application properties. This patch is heavily inspired from rabbitmq, and works a lot better than previous attemps. While I was here, I removed the need of an application section, let couchdb loads daemons as usual. Tested with couchapp_ng and geocouch.
        Hide
        Paul Joseph Davis added a comment -

        Reading through the docs there are some scary bits here:

        On the code path cache:

        "To activate it, start the emulator with the command line flag -code_path_cache or call code:rehash(). When the cache is created (or updated), the code server searches for modules in the code path directories. This may take some time if the the code path is long."

        Then there's the section on new vs old code that we're all familiar with from the config with exported functions and what not that's also important to consider.

        I see your point about what type of daemon that's started isn't configurable as of yet, but I think it'd be better to approach this from the point of view of loading a set of services that includes the rest of CouchDB rather than having lots of other bits.

        I'm also not reading too thoroughly, but restarting all secondary services when any one of them changes seems like not a good idea.

        As to the code paths and $PREFIX/couchdb/erlang/lib thing, I think you're missing a step when you say "add a plugin via the HTTP interface" because you still have to put the actual code on the machine. Rather than letting people put code all over the filesystem and then make us have to deal with dynamically changing code paths, I'd still much prefer having a single place that people can put code (or perhaps a list of places that is also configurable for packagers).

        I don't see this as too onerous either. Someone had to do "cp my_app/ /random/path/to/my_app" so there's no reason they can't do "cp my_app `pkg-config --variable=erl_libs`".

        Or in other words, this looks on the outside like its a trivial patch but my instincts are telling me that this direction is going to turn into a mess of edge conditions and crazy behavior that we can't predict. The goals I think are good, but I think we should look for a simpler solution that's more consistent across all of couch.

        Show
        Paul Joseph Davis added a comment - Reading through the docs there are some scary bits here: On the code path cache: "To activate it, start the emulator with the command line flag -code_path_cache or call code:rehash(). When the cache is created (or updated), the code server searches for modules in the code path directories. This may take some time if the the code path is long." Then there's the section on new vs old code that we're all familiar with from the config with exported functions and what not that's also important to consider. I see your point about what type of daemon that's started isn't configurable as of yet, but I think it'd be better to approach this from the point of view of loading a set of services that includes the rest of CouchDB rather than having lots of other bits. I'm also not reading too thoroughly, but restarting all secondary services when any one of them changes seems like not a good idea. As to the code paths and $PREFIX/couchdb/erlang/lib thing, I think you're missing a step when you say "add a plugin via the HTTP interface" because you still have to put the actual code on the machine. Rather than letting people put code all over the filesystem and then make us have to deal with dynamically changing code paths, I'd still much prefer having a single place that people can put code (or perhaps a list of places that is also configurable for packagers). I don't see this as too onerous either. Someone had to do "cp my_app/ /random/path/to/my_app" so there's no reason they can't do "cp my_app `pkg-config --variable=erl_libs`". Or in other words, this looks on the outside like its a trivial patch but my instincts are telling me that this direction is going to turn into a mess of edge conditions and crazy behavior that we can't predict. The goals I think are good, but I think we should look for a simpler solution that's more consistent across all of couch.
        Hide
        Benoit Chesneau added a comment -

        " I'd rather stick to the config tool that lets people install their code into the $PREFIX/couchdb/erlang/lib directory and keep the static code paths that we already use."

        The problem with such things is that you can't just add a plugin via the HTTP interface if needed. They all have to be known fisrt. Also when you have more tha 10 plugins (event 3) shell environment start to be huge.

        Show
        Benoit Chesneau added a comment - " I'd rather stick to the config tool that lets people install their code into the $PREFIX/couchdb/erlang/lib directory and keep the static code paths that we already use." The problem with such things is that you can't just add a plugin via the HTTP interface if needed. They all have to be known fisrt. Also when you have more tha 10 plugins (event 3) shell environment start to be huge.
        Hide
        Benoit Chesneau added a comment - - edited

        Here is a second patch that use code:rehash. It forces erlang to reload code path cache. Also it allows to dynamically reload modules on config changes. It force the secondary supervisor to restart so it should also restart all services attached but I may be wrong about that.

        The reason I use a daemon section here, is to allows a plugin to be loaded as a supervisor or as a worker. So we can have different shutdown type in supervision. Which isn't handled by couchdb. Maybe it could be addressed in daemons though.

        Show
        Benoit Chesneau added a comment - - edited Here is a second patch that use code:rehash. It forces erlang to reload code path cache. Also it allows to dynamically reload modules on config changes. It force the secondary supervisor to restart so it should also restart all services attached but I may be wrong about that. The reason I use a daemon section here, is to allows a plugin to be loaded as a supervisor or as a worker. So we can have different shutdown type in supervision. Which isn't handled by couchdb. Maybe it could be addressed in daemons though.
        Hide
        Paul Joseph Davis added a comment -

        Two things concern me about this code.

        First bit is I don't see why we'd need to specify a daemon in a plugin section and then deal with that. We've already got a section in the config starting daemons and plugins are free to define their own sections in the INI.

        The second bit is dynamically adding code paths to the Erlang VM. Specifically, they're never getting removed when the plugin goes away and even if we could do that, what happens to code running that was loaded from a path that is about to be deleted? I'd rather stick to the config tool that lets people install their code into the $PREFIX/couchdb/erlang/lib directory and keep the static code paths that we already use.

        Show
        Paul Joseph Davis added a comment - Two things concern me about this code. First bit is I don't see why we'd need to specify a daemon in a plugin section and then deal with that. We've already got a section in the config starting daemons and plugins are free to define their own sections in the INI. The second bit is dynamically adding code paths to the Erlang VM. Specifically, they're never getting removed when the plugin goes away and even if we could do that, what happens to code running that was loaded from a path that is about to be deleted? I'd rather stick to the config tool that lets people install their code into the $PREFIX/couchdb/erlang/lib directory and keep the static code paths that we already use.
        Hide
        Benoit Chesneau added a comment -

        Good version of the diff.

        Show
        Benoit Chesneau added a comment - Good version of the diff.
        Hide
        Benoit Chesneau added a comment -

        bad copy paste fixed

        Show
        Benoit Chesneau added a comment - bad copy paste fixed

          People

          • Assignee:
            Unassigned
            Reporter:
            Benoit Chesneau
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development