Bug #98667 "All pipe instances are busy" exception on multiple connections to named Pipe
Submitted: 19 Feb 2020 12:55 Modified: 26 Sep 2020 1:37
Reporter: Veera P Email Updates:
Status: Closed Impact on me:
None 
Category:Connector / J Severity:S2 (Serious)
Version:8.0.17 OS:Windows
Assigned to: CPU Architecture:Any
Tags: All pipes, Busy

[19 Feb 2020 12:55] Veera P
Description:
We are using mysql-connector-java-8.0.17.jar to connect to mysql DB via sockets. Sometimes we see \\.\pipe\MySQL (All pipe instances are busy) issue when we try to connect to open multiple connections. Not sure this reproduces all the windows machines, but we observe this when windows connected to domain network.

Similar issue also reported on MariaDB and other open source connectors, where they had already fixed. Here is the link to them:
https://jira.mariadb.org/browse/CONJ-435
https://sourceforge.net/p/jtds/bugs/437/

Stack traces will be attached soon.

How to repeat:
There is no special case here to reproduce, but we observe this, when we login to machine which is placed on domain network, as user and run the process (which intern installs mysql and start) as admin, and trying to connect to DB after successful start of mysql.

Suggested fix:
I believe, when pipes are busy issue occurred, retry connection may fix issue.
[19 Feb 2020 12:57] Veera P
Stacktrace to the bug

Attachment: stacktrace.log (application/octet-stream, text), 8.66 KiB.

[5 Aug 2020 0:23] Filipe Silva
Hi Veera,

Thank you for your interest in MySQL Connector/J.

Bug verified as described.
[26 Sep 2020 1:37] Daniel So
Posted by developer:
 
Added the following entry to the C/J 8.0.22 changelog: 

"When trying to open multiple connections to a MySQL server using Connector/J with a named pipe on Windows systems, the attempt sometimes failed with the 'All pipe instances are busy' error. With this fix, if a timeout has been set using the connection property connectTimeout or the method DriverManager.setLoginTimeout(), Connector/J will retry opening the named pipe repeatedly until the timeout is reached or the named pipe is opened successfully. As a side-effect of this new behavior, there will be a delay, equal to the length of the timeout, for throwing an error for a failed named-pipe connection even when it is caused by an error other than 'All pipe instances are busy.'"