Under heavy load some of the basic network operations could fail which led
to some of the allocated memory to leak.
Also the backend protocol never freed the current protocol command if it
was not completed. This would happen if a user executed a session command
as the first command but backend authentication would fail.
Fetching the users may potentially take longer than the watchdog
timeout. To ensure that MaxScale is not killed by systemd, we must
ensure that the notifications are generated also when MaxScale
synchronously is fetching the users.
Some rearrangements to ensure that what should be private
can be kept private.
- WatchdogNotifier made a friend.
- WatchdogWorkaround defined in RoutingWorker and made a friend.
- mxs::WatchdogWorker defined with 'using'.
The systemd watchdog mechanism requries notifications at
regular intervals. If a synchronous operation of some kind
is performed by a worker, then those notfications will not
be generated.
This change provides each worker with a secondary thread that
can be used for triggering those notifications when the worker
itself is busy doing other stuff. The effect is that there will
be an additional thread for each worker, but most of the time
that thread will be idle.
Sofar only the mechanism; in subsequent changes the mechanism
will be taken into use.
The servers with a zero weight would be always used over ones that have a
weight. This means that the behavior was inverted and caused the
mxs2054_hybrid_cluster test to fail in 2.3.
Also fixed a typo in the deprecation message.
Exclude systemd usage if the library is not installed.
Only excluding what is necessary. This keeps the object size the
same and still compiles most of the code.
Systemd wathdog notification at a little more than 2/3 of the
systemd configured time. In the service config (maxscale.service)
add e.g. WatchdogSec=30s to set and enable the watchdog.
For building: install libsystemd-dev.
The next commit will modify cmake configuration and code to
conditionally compile the new code based on existence of libsystemd-dev.
By exposing a (currently undocumented) debug endpoint that lets one
monitor interval pass, we make the reuse of the monitor waiting
functionality a lot easier. With it, when MaxScale is started by the test
framework it knows that at least one monitor interval will have passed for
all monitors and that the system is ready to accept queries.
This will simply cause a task to be posted to each worker.
If the workers are running normally, the task will reach the
workers and the associated semaphore posted, and the REST-API
call will return. If any worker is not running normally, the
task will not be processed and the REST-API call will hang.
Whether or not a session should retain its statements is now
a property of the session. This in preparation for making the
whole functionality a property that can be enabled and disabled
at runtime, of the service.
As the router is the only one that knows what backends a particular
statement has been sent to, it is the responsibility of the router
to keep the session bookkeeping up to date. If it doesn't we will
know what statements a session has received (provided at least some
component in the routing chain has RCAP_TYPE_STMT_INPUT capability),
but not how long their processing took. Currently only readwritesplit
does that.
All queries are stored and not just COM_QUERY as that makes the
overall bookkeeping simpler; at clientReply() time we do not need to
know whether or not to bookkeep information, we can just do it.
When session information is queried for, we report as much information
we have available.
The old 'passwd' parameter is now converted to the 'password' parameter
and a warning about its deprecation is logged. This keeps the mandatory
parameter detection functional while still allowing old-style
configurations to be used.
This is currently disallowed for the server parameter, as the value could be
read/written concurrently. The monitor parameter can be changed since the
monitor is stopped during write.
The removed statistics variables have no meaning anymore and
were not updated.
Decided to simply drop the variable from the JSON output. It
gets far too rigid if fields of objects cannot be changed without
bumping the REST-API version.
This commit introduces the plumbing support for obtaining
classification information of a statement using the REST-API.
It introduces a URL like
/v1/maxscale/query_classifier/classify?sql=SELECT+1
that in the response will return a JSON object with the
information. Subsequent commits will provide the actual
information.
Even though directly closing the socket is not very neat in the
architectural sense of things, it allows the best of both worlds: the
socket is instantly closed and is open for reuse while the listener struct
is still available as a reference.
This change needs to be revised when the listeners are refactored into
separate objects.
Updated documentation to reflect the change in behavior.
If a listener is defined in a static configuration file, it can now be
destroyed at runtime. If MaxScale is restarted, the listener will be
created again unless the configuration file is modified.
The cache size now refers to the total memory used by the cache instead of
the per thread limit. This makes it easier to use as well as more
predictable by removing the dependency on the number of worker threads.
The admin files are now created with 640 permissions and automatically
created directories now properly set the permissions for the group as
well. All files and directories created by avrorouter and binlogrouter
also now correctly limit the read and write permissions only to the owner
and the group.
