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.
By truncating the files, tests can be run while the log is being
tailed. If they are removed, the files need to be reopened each time a
test is started.
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 safest way to stop the avrorouter is to stop replication and wait for
the conversion to halt. This was not previously documented and needs to be
mentioned in the router documentation.
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.
