Removed unused and properly documented all entry points in the protocol
module API. As the removal of the `session` entry point is an backwards
incompatible change, the protocol API version was updated.
The connections that relate to a particular session are now a part of the
sessions resource. Currently, only the generic information is stored for
each connection (id and server name).
Now that the set of DCBs is stored in the session, it can be used to speed
up the handling of the KILL command processing by stopping when the first
related DCB is found.
By storing a link to the backend DCBs in the session object itself, we can
reach all related objects from the session. This removes the need to
iterate over all DCBs to find the set of related DCBs.
DCBs will only be used in conjunction with RoutingWorkers and
hence RoutingWorker and not just Worker must be used when looking
for the current worker and worker id.
The reason is that RoutingWorker cheats; the current worker id is
set to 0 at initialization time, which indicates that a worker would
be running although it isn't.
The reason is that as listeners are created before any worker has
been started, that arrangement ensures that listening DCBs are
book-kept in the worker running in the main thread.
Now, that is a kludge. It ought to be changed so that a, say,
MainRoutingWorker class is introduced that in its run function
initializes MaxScale and then continues running as any regular
RoutingWorker. In due time.
- If a client DCB should be moved to some other worker than
the current one (cli and maxinfo), and that fails, the
thread id must be reset to that of the calling thread as
otherwise asserts will be triggered.
- If the creation of the first DCB fails, then the dcb list
for that thread will be NULL and thus must be accessed
with some caution.
When the pipe buffer size is maximized, the message queue can hold more
messages. This will mitigate the problem of too many messages being placed
in the queue.
When DCBs are being hung in dcb_hangup_foreach, the hangup event can be
processed directly. This prevents excessive use of the worker message
queue pipe thus reducing the possibility of it being full.
The fact that a client dcb was immediately added to the epoll-
instance of the relevant worker (possible, since that is thread-
safe), but was added to the book-keeping via the message mechanism
(necessary, since that is not thread-safe), meant that if the
connection was closed before the message was delivered, the handling
of the message then caused an access error.
Now the fd is also added to the epoll-instance via the messaging
mechanism, so the problem can no longer occur. The only fds this
affects are connections made to maxadmin or maxinfo as they are
always handled by the main thread due to deadlock issues.
Using delayed_call rather than usleep. This caused a fair amount of changes to
the timing ascpects (or delaying). Also some other small changes; more config
and all durations in milliseconds.
Since we need to call mysql_thread_init(), which can fail, in
the monitor thread, we need to wait for the outcome of that
before we can return from start().
The configuring of the monitor instance is now performed in a
separate function. That is in preparation for the moving of the
start function to maxscale::MonitorInstance.
- All monitors (but MariaDBMon for the time being) inherit
from that.
- All common member variables moved to that class. Still
manipulated in derived classes.
In subsequent commits common functionality will be moved to
that class.
If the feature is enabled (default off), at the end of a monitor loop
(once server states are known), read_only is enabled on slaves servers
without it.
To work around the limitation in the session command handling and
multi-part results, all session commands are now treated as gathered
results. This allows session commands which return result sets to be used
with MaxScale.
This change should not cause problems with practical workloads as they
usually do not return massive resultsets for session commands.
The optimal way to handle the multi-part responses would be to integrate
it into the result completion tracking process. This would allow the
prepared statement IDs to be extracted while the command is being
processed.
By relying on the server to tell us that it is requesting the loading of a
local infile, we can remove one state from the state machine that governs
the loading of local files. It also removes the need to handle error and
success cases separately.
A side-effect of this change is that execution of multi-statement LOAD
DATA LOCAL INFILE no longer hangs. This is done by checking whether the
completion of one command initiates a new load.
The current code recursively checks the reply state and clones the
buffers. Neither of these are required nor should they be done but
refactoring the code is to be done in a separate commit.
Added two helper functions that are used to detect requests for local
infiles and to extract the total packet length from a non-contiguous
GWBUF.
The logic was weird, as the permission checking function assumes a disconnected
server as fine. The checking is now done when starting the main loop and lacking
grants print errors but does not stop the monitor.
