For external parsing there will be a separate process that handles
parse requests sent from MaxScale. From MaxScale's perspective there
will just be a specific query classifier plugin that upon startup
launches that external process and manages its lifetime. That is,
MaxScale proper will be completely oblivious of this arrangement.
The skeleton process introduced here does nothing; just sits in
a loop sleeping. The skeleton query classifier plugin currently
loads the MySQL embedded query classifier and performs parsing
using it. That way the external process based query classifier can
immediately be used.
Next step is to introduce process management into the picture without
actually moving the parsing anywhere.
Now, qc_mysqlembedded is linked against MySQL's embedded library,
and MaxScale itself against Connector-C.
So, in order to build MaxScale, Connector-C must be installed.
This has been tested with Connector-C 2.2.1.
The build variable MYSQLCLIENT_LIBRARIES is no longer used.
The query_classifier library is now only a wrapper that loads an
actual query classifier implementation. Currently it is hardwired
to load qc_mysqlembedded, which implements the query classifier
API using MySQL embedded.
This will be changed, so that the library to load is specified
when qc_init() is called. That will then allow the query classifier
to be specified in the config file.
Currently there seems to be a conflict between the mysql_library_end()
call made in qc_mysqlembedded and the mysql_library_end() call made in
gateway.c. The reason is that they both finalize a shared library.
For the time being mysql_library_end() is not called in gateway.c.
This problem is likely to go away by switching from the client
library to the connector-c library.
Currently not used, but the existing query_classifier will be
changed into being just a wrapper around a dynamically loaded
query classifier plugin, i.e. qc_mysqlembedded.
Only the query classifier needs the functionality of the embedded
server, while the rest of MaxScale is content with the client
library or Connector/C.
This have now been rearranged so that query-classifier links with
the embedded static library and then explicitly exports its own
functions using the query_classifier.map linker script. That way
query classifier will use the embedded library, while the rest of
maxscale use the client library, and this without conflicts.
Currently, query_classifier is not linked to maxscale-common,
but executables must link to maxscale-common and query_classifier.
This is the first change in an attempt to arrange the linking so that
more errors are detected at link-time.
- All files in server/core but for gateway.c are linked to one shared
library called maxscale-common.
- The files log_manager/log_manager.cc and utils/skygw_utils.cc are
built into maxscale-common as well.
- MaxScale itself consists now only of gateway.c and is linked with
maxscale-common.
- All plugins link with maxscale-common.
- All executables link in addition with {EMBEDDED_LIB}.
After this change, the change (MXS-517) where query_classifier is the
only component that uses ${EMBEDDED_LIB} and the rest mysqlclient can
be made much cleaner.
After a few additional steps, all shared libraries can be linked with
the linker flags "-Wl,-z,defs", which directs the linker to resolve
all symbols. That will require that all shared libraries list all the
libraries they need, but will at the same time ensure that any
missing symbols are detected at link-time and not at run-time.
The soname version numbers were missing from all the library targets
properties which caused ldconfig to warn about non-symlink libraries
being installed.
