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?
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
Vladislav Vaintroub
added a comment - - edited 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
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.
Vladislav Vaintroub
added a comment - - edited 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.
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?
Georg Richter
added a comment - 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! 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.
Vladislav Vaintroub
added a comment - 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.
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 loaded
FATAL: `thread_init' function failed: ./src/lua/oltp_common.lua:356: connection creation failed
FATAL: Threads initialization failed!
If I try anything with more than 1 thread.
With above, plugin support of this kind seems to be rather fragile.
Vladislav Vaintroub
added a comment - - edited 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 loaded
FATAL: `thread_init' function failed: ./src/lua/oltp_common.lua:356: connection creation failed
FATAL: Threads initialization failed!
If I try anything with more than 1 thread.
With above, plugin support of this kind seems to be rather fragile.
People
Georg Richter
Vladislav Vaintroub
Votes:
0Vote for this issue
Watchers:
4Start watching this issue
Dates
Created:
Updated:
Resolved:
Git Integration
Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.
[{"id":-1,"name":"My open issues","jql":"assignee = currentUser() AND resolution = Unresolved order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":true},{"id":-2,"name":"Reported by me","jql":"reporter = currentUser() order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":true},{"id":-4,"name":"All issues","jql":"order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-5,"name":"Open issues","jql":"resolution = Unresolved order by priority DESC,updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-9,"name":"Done issues","jql":"statusCategory = Done order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-3,"name":"Viewed recently","jql":"issuekey in issueHistory() order by lastViewed DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-6,"name":"Created recently","jql":"created >= -1w order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-7,"name":"Resolved recently","jql":"resolutiondate >= -1w order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-8,"name":"Updated recently","jql":"updated >= -1w order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false}]
It looks like this patch was pushed, back in May.