[CONC-644] Make named pipe "plugin" a builtin on Windows by default Created: 2023-05-02  Updated: 2023-05-04

Status: Open
Project: MariaDB Connector/C
Component/s: None
Affects Version/s: None
Fix Version/s: 3.3.5

Type: New Feature Priority: Major
Reporter: Vladislav Vaintroub Assignee: Georg Richter
Resolution: Unresolved Votes: 0
Labels: 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?

 Comments   
Comment by Vladislav Vaintroub [ 2023-05-02 ]

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.

Comment by Vladislav Vaintroub [ 2023-05-02 ]

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.

Comment by Georg Richter [ 2023-05-02 ]

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?

Comment by Vladislav Vaintroub [ 2023-05-04 ]

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.

Comment by Vladislav Vaintroub [ 2023-05-04 ]

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

Generated at Thu Feb 08 03:06:47 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.