[WinError 10061] No connection could be made because the target machine actively refused it

[amotl]

Problem Report

When connecting to CrateDB using SQLAlchemy, the client raises an exception like this.

[WinError 10061] Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte

[WinError 10061] No connection could be made because the target machine actively refused it

>           raise ConnectionError(
                ("No more Servers available, "
                 "exception from last server: %s") % message)
E           sqlalchemy.exc.OperationalError: (crate.client.exceptions.ConnectionError) No more Servers available, exception from last server: HTTPConnectionPool(host='crate', port=4200): Max retries exceeded with url: /_sql?types=true (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x000001F4B50F0AF0>: Failed to establish a new connection: [WinError 10061] Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte'))
E           [SQL: SELECT name FROM sys.nodes]
E           (Background on this error at: https://sqlalche.me/e/20/e3q8)

.venv\lib\site-packages\crate\client\http.py:601: OperationalError

[amotl]

Problem Cause

WinError 10061 means the host actively refused the TCP connection, by responding with a TCP RST packet. In turn, that means that the host IP stack is up and running, but, most likely, no service is listening on that ip/port combination where the client attempts to connect to.

Return code/value	Description
WSAECONNREFUSED 10061	Connection refused. No connection could be made because the target computer actively refused it. This usually results from trying to connect to a service that is inactive on the foreign host—that is, one with no server application running.

-- https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2

[amotl]

Hi again,

this report, together with #628, was coming from a scenario where a user is building a test case, which connects to an invalid destination on purpose, in order to validate how the Python driver behaves in this situation.

The improvement coming from #571 resolved the problem well:

I've implemented the timeout with the new version and it seems to work on both Linux and Windows. With a timeout of 0.1s, connecting to an invalid host takes about 2.5s to effectively time out, which is fine. When using an invalid port, the connection aborts immediately. Thanks for your effort!

With kind regards,
Andreas.