Details
-
New Feature
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
None
Description
The server has compiled named pipe as builtin for ages now.
But current default compilation still puts it into pvio_npipe.
It is a bit frustrating to take the libmariadb from package manager (I'm using vcpkg), compile it, and not being able to connect to server via named pipe.
The context is using for sysbench (on Windows), and sysbench does not give you options to specify mariadb plugin directories. There are no option files, and there are no environment variables, or predefined paths (relative to executable location), where it can be put in.
While libmysql (from Oracle) does accomplish connecting via named pipe, I prefer libmariadb, as it does have optimizations that libmysql does not have, e.g not resending result metadata for prepared statements.
named pipe turns out much faster than TCP on Windows, so for sysbench it is important to have it.
Granted, I can use ExternalProject_Add or submodules, but I prefer not touse them. Named pipe as "transport layer" is solid and is used in different scenarios (with the server, mysql_upgrade_service would use it), so would it be possible to have it compiled in?
Attachments
Activity
Thanks! It is a new feature and there is a multithreading bug : Plugin xxx could not be loaded : it is already loaded, though the later probably deserves a different bug report.
wlad I merged it into 3.3 - could you please provide a short test case about the "already loaded bug" - we are closing 3.3.5 due to the upcoming CE server release tomorrow.
Do you still load the plugin via api call?
Thanks for the patch. The short test is not so easy to provide, my context is sysbench, and it does a lot of things concurrently, with as many threads as passed to threads parameter. I was not using API calls myself, just placed the plugin next to executable. Neither sysbench does any of the plugin API calls. I used mysql-host=. sysbench parameter, which would use named pipe, which was not compiled in, and with single thread it plugin was loaded, and with many threads it failed.
However the bug is obvious from just looking at the code . If you have 2 threads executing
ma_pvio_init at the same time, not finding the vio plugin, at the same time. both try to load plugin. One thread loads the plugin, while another one will get "already loaded", after it waited on mutex.
Why is "already loaded" an error at all? IT should not be
Accomplished to find the location where it is loaded from . next to executable is fine.
Now, it tells me "plugin can't be loaded, it is already loaded" with more than 1 thread.
FATAL: unable to connect to MySQL server on host '.', port 3306, aborting...FATAL: error 2059: Plugin pvio_npipe could not be loaded: it is already loadedFATAL: `thread_init' function failed: ./src/lua/oltp_common.lua:356: connection creation failedFATAL: Threads initialization failed!If I try anything with more than 1 thread.
With above, plugin support of this kind seems to be rather fragile.