Allocating the session before a DCB guarantees that at no point will a DCB
have a null session. This further clarifies the concept of the session and
also allows the listener reference to be moved there.
Ideally, the session itself would allocate and assign the client DCB but
since the Listener is the only one who does it, it's acceptable for now.
As each connection now immediately gets a session the dummy session is no
longer required. The next step would be to combine parts of the session
and the client DCB into one entity. This would prevent the possibility of
a client DCB with no associated session. Backend DCBs are different as
they can move from one session to another when the persistent connection
pool is in use.
Whenever a client DCB is accepted, a session for it is allocated. This
simplifies the handling of shared data between DCBs by allowing it to be
placed inside the session object. Currently, the data is stashed away in
the client DCB.
By doing the actual accepting of the new DCB in the core, the protocol
modules can only do the actual protocol level work. This removes some of
the redundant code that was in the protocol modules.
Allocating DCB with new allows the use of C++ objects in the DCB
struct. Also the explicit poll field can be replaced by inheriting from
MXB_POLL_DATA.
Modified the functions to use a listener instead of a DCB in the accepting
process. This removes some of the dependenices that the listeners have on
the DCB system.
If the client sends two different sets of capability bits during the
authentication phase of an SSL enabled connection, both sets need to be
combined. This prevents capabilities from degrading mid-connection which
is the case when Oracle Connector/J drops the SSL capability bit
mid-authentication.
If the service doesn't require collection of complete packets, the user
reauthentication done with COM_CHANGE_USER would be skipped. This caused
the change_user test to fail.
By temporarily switching to full packet collection mode for the duration
of the COM_CHANGE_USER, we avoid duplicating the code for the streaming
router types.
If the initial handshake that is sent by the accepting thread is buffered,
the subsequent flushing of it is done by the owning thread. As
cross-thread buffer usage is not allowed, the initial handshake must be
sent by the owning thread.
The intention was to send the lowest backend version string automatically
to the client instead of the default handshake version. This did not work
as the service version string was used instead of the server version.
See script directory for method. The script to run in the top level
MaxScale directory is called maxscale-uncrustify.sh, which uses
another script, list-src, from the same directory (so you need to set
your PATH). The uncrustify version was 0.66.
By storing the data gathere by readwritesplit inside the session, the
protocol will be aware of the state of the LOAD DATA LOCAL INFILE
execution. This prevents misinterpretation of the data which previously
led to closed connections, effectively rendering LOAD DATA LOCAL INFILE
unusable.
This change is a temporary solution to a problem that needs to be solved
at the protocol level. The changes required to implement this are too big
to add into a bug fix release.
If a large packet is received, the stack would overflow when the username
size was determined from the packet size. The code must not assume
anything about the size of the packet being read.
The ssl parameters were defined as strings even thought they were actually
enums. The events parameter was also a string even though it was an enum.
Also added the missing "all" value to the events enum. This fixes the
regression of scripts not being launched on all events by default.
Moved the definition of the default version string where it should be and
removed the empty value check.
As all connections should be accepted via dcb_accept, it is the optimal
place to calculate how many open client connections per service there
are. The decrementation should be done when the session is closed instead
of when the call to dcb_close for the client DCB is done. This allows the
client count to be the absolute reference count that sessions have to a
service.
The current client count is a duplicate counter that should match the
n_current value in SERVICE_STATS. The former does differ from the latter
in that it does the incrementation when the client DCB is accepted instead
of when the session is created.
If a client is executing a COM_CHANGE_USER command and the
reauthentication of the client fails, no error message would be logged
about the failure of the reauthentication process and only a routing
failure message would be logged.
