When a cloned DCB is created, the service pointer is not copied and it
needs to be manually set in the newSession entry point. This most likely
due to the fact that the cloned DCB always has a different service and it
is not possible to deduce it.
Another option would be to pass the target service as a parameter but the
whole DCB cloning process could use with a rewrite so any modifications
beyond the required minimum are wasteful.
The example in the epoll(7) manpage only sets the EPOLLIN event flag.
Although it is not explicitly stated that only EPOLLIN events arrive for
sockets that are listening, any other types of events should not be
relevant for listeners.
If a connection has not been fully established (i.e. authentication has
been completed) then it should not be considered as a connection pool
candidate.
MariaDB GTID Master registration:
creating missing binlog files (with 4 byes) between current one and the
filename coming from ROTATE_EVENT.
blr_slave_binlog_dump() is also checking possible empty files.
This was originally removed, since it was checking the same word
twice. However, the parsing is clearer with it and the cost is only
paid when the KILL is detected, which is very rare.
Also, fix some incorrect parsing.
The text-version of "KILL CONNECTION" command is now supported. To keep the
overhead low, only minimal parsing is done on the query. The query
needs to start in the beginning of the mysql-packet, have no comments
and have limited whitespace as the total length of the query is limited.
Both "KILL 123" and "KILL CONNECTION 123" are accepted.
"KILL QUERY 123" is also accepted but not acted on, as it requires larger
changes.
The server internal session id may be larger than 4 bytes (MariaDB uses 8)
but only 4 are sent in the handshake. The full value can be queried
from the server, but this query is not supported by MaxScale yet. In any
case, both the protocol and MXS_SESSION now have 64 bit counters. Only the
low 32 bits are sent in the handshake, similar to server.
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 REST API now supports the If-Modified-Since, If-Unmodified-Since,
If-Match and If-None-Match headers and returns the correct response if the
conditional fails.
Added tests for the date parsing and expanded the HTTP header tests in the
REST API test suite.
The resource system now tracks both the time when a resource was last
modified and the revision number of the resource. This allows working
Last-Modified and ETag headers to be generated by the REST API.
The If-Modified-Since and If-None-Match request headers are not yet
processed and using them will always return the resource instead of a 304
Not Modified response.
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.
If a request to the `/` resource is made, the API responds with an 200
OK. This is done to make it possible to use the HTTP health check
mechanism found in many cloud load balancers.
Returning 204 No Content removes the cost of always sending back the
modified resource. If the modified resource is required, a GET request
should be made to retrieve it.
Updated tests to account for this change.
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 API specification suggests that the API returns the 403 Forbidden
error when the user does an invalid request. The 400 Bad Request isn't the
ideal error for cases where the syntax is correct but the action being
performed is wrong.
The creation and modification of moitor now supports the JSON API
conforming format generated by the GET endpoints.
Also added tests for creating and altering monitors via the REST API.
The tests now automatically start MaxScale before each test block and stop
it and perform cleanup after the test. This is done by simply calling the
`before.sh` and `after.sh` scripts before each test block.
The `test_rest_api` make target creates a discardable installation of
MaxScale which is used to launch a local instance of MaxScale. This local
instance is then used to test the REST API.
This is definitely not an efficient way to test the MaxScale but it allows
local testing without virtual machines or containers.
Using the JSON Pointer syntax specified in RFC 6901
(https://tools.ietf.org/html/rfc6901) allows for a convenient way to
access values deep in a JSON object.
