Only used in conjunction with queued connections, which are not
enabled anyway. Once that comes on the table again, better to use
some standard data structures.
Only the protocol, port and address of the listener were used to check if
a listener exists. The check should also use the name of the listener to
be sure that each name is unique.
Expanded tests to check that the creation of duplicate listeners is
detected. Did minor improvements to related test code.
The listeners are now a proper sub-resource of the service resource. This
means that it acts like a normal resource and can be queried both as a
collection of resources and as an individual resource.
The feedback system wasn't used and was starting to cause problems on
Debian 9 where the libcurl required different version of OpenSSL than what
MaxScale was linked against.
That allows the version to be updated and read atomically. If
major/minor/patch are stored as separate variables, you can get an
inconsistent set. Now it may be out of date by the time it is used,
but it will never be internally inconsistent.
The behaviour of the query classifier needs to change depending
on the version of the servers of a service. With this function
"some" version of the service can be obtained.
The top level resource self links pointed to the collection instead of the
resource itself. The individual resoures now also have a links field that
contains the self link to the resource. This should make navigation of the
API easier as all objects have valid links in them.
The listener iterator hides the details of the listener iteration behind a
small set of functions.
The following for-loop demonstrates the main use-case for the iterator:
LISTENER_ITERATOR iter;
for (SERV_LISTENER *listener = listener_iterator_init(service, &iter);
listener; listener = listener_iterator_next(&iter))
{
/** Do something with the listener */
}
As the listeners are mostly iterated to either check a fact about them or
print their information, the functions cater to that use-case. For this
reason, they should always be allocated off the stack.
The service port list is now iterated in a safe and lock-free manner. This
makes the handling of service ports somewhat simpler since once an item
has been added to the list it will never be removed. It also removes the
need to lock the service when checking whether a service listens on a port
which caused potential deadlocks.
The listeners under the /services/:service/listeners collection are now
fully JSON API compliant resources.
The listeners could also be exposed as a /listeners collection to easily
group all listener type resources in one place. This approach does has
some semantical and practical problems, namely the fact that each listener
has a many-to-one relationship with its service and listeners by
themselves can't exist alone.
The JSON objects that are created from the various core MaxScale objects
share a lot of common code. Moving this into a separate files removes the
redundant code.
The filter names for the service parameter `filters` weren't converted
into the new format. This caused a configuration error when a filter with
significant whitespace in its name was used in a service.
When a persisted configuration file is read, the values in it are
considered to be more up-to-date than the ones in the main configuration
file. This allows all objects to be persisted in a more complete form
making it easier to change configuration values at runtime.
This change is intended to help make runtime alterations to services
possible.
The `user`, `password`, `version_string` and `weightby` values should be
allocated as a part of the service structure. This allows them to be
modified at runtime without having to worry about memory allocation
problems.
Although this removes the problem of reallocation, it still does not make
the updating of the strings thread-safe. This can cause invalid values to
be read from the service strings.
The service, filter and monitor resources now have a "parameters" value
which contains a set of all configuration parameters for that object. This
set contains both standard and non-standard parameters.
Also fixed a mistake in the constant name definitions for the monitor
parameters "events" and "script".
The service resource now exposes the parameters that were given to
it. This allows general service parameters to be changed at runtime
through the REST API.
A self link to the resource itself provides a convenient way for the
client to request a resource, modify it and call the self link to update
it. This removes some of the burden on the client to keep track of the
resource links by placing these in the resource itself.
The relationships from servers to services and monitors and filters to
services were not implemented. Now each server lists the services and
monitors that use it and each filter lists the services that use the
filter.
This enables the creation of a server and linking of that server to
services and monitors in one atomic operation.
The JSON API (http://jsonapi.org/) specifies a way to express relations in
a somewhat generic way. By moving towards a more generic schema for the
resources, it will be easier to handle the modification of the relations
between these resources.
When a resource has a relation to another resource, it should be expressed
as a working link to the resource. By passing the hostname of the server
to the functions, we are able to generate working relation links.
If a resource can be accessed from more than one place, it should be a
link. The previous change that duplicated the content for nested resources
wasn't a very clean solution. With links, the content is easier to browse
using a normal browser.
The modules that implement a diagnostics entry point now return a JSON
type object. This removes the need to format data inside the modules.
The module implementations of these are not yet complete which means that
MaxScale will fail to compile.
As a service is a collection of other resources, it makes sense to expand
those resources that were previously expressed as relative paths. This way
the API can be readily consumed without altering the pathnames to
links. The downside to this is the increased bandwidth consumption and
possible excess data.
The functions don't modify the filters when the JSON is generated. This
means that the parameters can be const.
Minor formatting fixes to service sources.
Both the filters and services can be queried via the REST API now that
these resources can be expressed in JSON format.
As with the other resources, these directly call the functions that
generate the data. This will be done via the inter-thread messaging system
once it's in place.
