Mention module commands in maxadmin document
The document explains how the module commands are used and gives an example how they could be used. Also fixed a few references to the old command names.
This commit is contained in:
parent
70ab537288
commit
88c62358fb
@ -1425,6 +1425,33 @@ until the next restart.
|
||||
Usage: destroy monitor NAME
|
||||
```
|
||||
|
||||
## Other Modules
|
||||
|
||||
Modules can implement custom commands called _module commands_. These are
|
||||
intended to allow modules to perform very specific tasks.
|
||||
|
||||
To list all module commands, execute `list commands` in maxadmin. This shows all
|
||||
commands that the modules have exposed. It also explains what they do and what
|
||||
sort of arguments they take.
|
||||
|
||||
If no module commands are registered, no output will be generated. Refer to the
|
||||
module specific documentation for more details about module commands.
|
||||
|
||||
To call a module commands, execute `call command <domain> <command>` in
|
||||
maxadmin. The _<domain>_ is the name of the module and _<command>_ is the
|
||||
command that should be called. The commands take a variable amount of arguments
|
||||
which are explained in the output of `list commands`.
|
||||
|
||||
An example of this is the `dbfwfilter` module that implements a rule reloading
|
||||
mechanism as a module command. This command takes a filter name as a parameter.
|
||||
|
||||
```
|
||||
maxadmin call command dbfwfilter rules/reload my-firewall-filter /home/user/rules.txt
|
||||
```
|
||||
|
||||
Here the name of the filter is _my-firewall-filter_ and the optional rule file
|
||||
path is `/home/user/rules.txt`.
|
||||
|
||||
# Tuning MariaDB MaxScale
|
||||
|
||||
The way that MariaDB MaxScale does it’s polling is that each of the polling
|
||||
|
@ -5,10 +5,10 @@ commands. They allow the modules to expand beyond the capabilities of the
|
||||
module API. Currently, only MaxAdmin implements an interface to the module
|
||||
commands.
|
||||
|
||||
All registered module commands can be shown with `maxadmin list functions` and
|
||||
they can be executed with `maxadmin call function <domain> <name> ARGS...` where
|
||||
_<domain>_ is the domain where the module registered the function and _<name>_
|
||||
is the name of the function. _ARGS_ is a function specific list of arguments.
|
||||
All registered module commands can be shown with `maxadmin list commands` and
|
||||
they can be executed with `maxadmin call command <domain> <name> ARGS...` where
|
||||
_<domain>_ is the domain where the module registered the command and _<name>_
|
||||
is the name of the command. _ARGS_ is a function specific list of arguments.
|
||||
|
||||
## Developer reference
|
||||
|
||||
@ -16,6 +16,8 @@ The module command API is defined in the _modulecmd.h_ header. It consists of
|
||||
various functions to register and call module commands. Read the function
|
||||
documentation in the header for more details.
|
||||
|
||||
**Note:** The domain should match the name of the module.
|
||||
|
||||
The following example registers the module command _my_command_ in the _my_module_ domain.
|
||||
|
||||
```
|
||||
|
Loading…
x
Reference in New Issue
Block a user