85b3d7c465501b79b2ec0cec0de9fa8b8326285b

The section name of a filter in the MaxScale configuration file is unique for each filter. Hence, by providing that name to the filter instance creation function, it is possible to act differently depending on which particular instance is being created. Case in point. There can be multiple cache filters defined in the MaxScale configuration file, each with a different set of rules, ttl and even backing store. Each cache will be backed by a separate storage that e.g. in the case of RocksDB will correspond to a particular path. In other words, for each cache instance corresponding to a particular cache definition in the MaxScale configuration file, we need to be able to create a unique path. If the filter section name (in the MaxScale configuration file) that anyways needs to be unique, is provided to the filter, then that name can be used when forming the unique path. The alternative is to require the DBA to provide some unique parameter for each cache definition, which adds configuration overhead and is errorprone. Furthermore, by providing the name to filters, also error messages can be customized for a particular section when appropriate.
# MaxScale by MariaDB Corporation The MariaDB Corporation MaxScale is an intelligent proxy that allows forwarding of database statements to one or more database servers using complex rules, a semantic understanding of the database statements and the roles of the various servers within the backend cluster of databases. MaxScale is designed to provide load balancing and high availability functionality transparently to the applications. In addition it provides a highly scalable and flexible architecture, with plugin components to support different protocols and routing decisions. MaxScale is implemented in C and makes extensive use of the asynchronous I/O capabilities of the Linux operating system. The epoll system is used to provide the event driven framework for the input and output via sockets. The protocols are implemented as external shared object modules which can be loaded at runtime. These modules support a fixed interface, communicating the entries points via a structure consisting of a set of function pointers. This structure is called the "module object". The code that routes the queries to the database servers is also loaded as external shared objects and are referred to as routing modules. An Google Group exists for MaxScale that can be used to discuss ideas, issues and communicate with the MaxScale community. Email: maxscale@googlegroups.com Forum: http://groups.google.com/forum/#!forum/maxscale Bugs can be reported in the MariaDB Corporation bugs database: https://jira.mariadb.org/projects/MXS/issues # Documentation For information about installing and using MaxScale, please refer to the documentation. It is in Markdown format. You can point your browser to the MaxScale project at GitHub. Look inside the "Documentation" directory, where you will find a file named Documentation-Contents.md. Click on that, and GitHub will show the documentation in its intended display format. The contents page lists the available documents and has links to them. If you do not want to rely on the internet, then clone the project from GitHub and point your browser to the Documentation-Contents.md file in your local file system and proceed as above.
Description
Languages
C
50.9%
C++
30.8%
Shell
3.7%
HTML
3.2%
Tcl
3.1%
Other
8.1%