ODBC timeout seems to take a lot longer than specified

Hi,

I am using func_odbc and I have one MySQL that is not accessible from the server that I am connecting from.
[pods]
dsn => asterisk-pods
username => pods
password => password
pre-connect => yes
sanitysql => select 1
max_connections => 300
forcecommit => no
connect_timeout => 5
negative_connection_cache => 300
logging => yes
slow_query_limit => 1000

I have the timeout set to 5 so why does it take almost 2 minutes to timeout? From my logs
[2024-09-17 09:40:07] VERBOSE[2932264] loader.c: Loading res_odbc.so.
[2024-09-17 09:40:07] DEBUG[2932264] config.c: Parsing /etc/asterisk/res_odbc.conf
[2024-09-17 09:40:07] DEBUG[2932264] res_odbc.c: Connecting pods(0x33e8f60)
[2024-09-17 09:40:27] DEBUG[2932272] threadpool.c: Worker thread idle timeout reached. Dying.
[2024-09-17 09:40:27] DEBUG[2932270] threadpool.c: Worker thread idle timeout reached. Dying.
[2024-09-17 09:40:27] DEBUG[2932269] threadpool.c: Worker thread idle timeout reached. Dying.
[2024-09-17 09:40:27] DEBUG[2932271] threadpool.c: Worker thread idle timeout reached. Dying.
[2024-09-17 09:40:27] DEBUG[2932266] threadpool.c: Destroying worker thread 4
[2024-09-17 09:40:27] DEBUG[2932266] threadpool.c: Destroying worker thread 2
[2024-09-17 09:40:27] DEBUG[2932266] threadpool.c: Destroying worker thread 1
[2024-09-17 09:40:27] DEBUG[2932266] threadpool.c: Destroying worker thread 3
[2024-09-17 09:40:27] DEBUG[2932268] threadpool.c: Worker thread idle timeout reached. Dying.
[2024-09-17 09:40:27] DEBUG[2932266] threadpool.c: Destroying worker thread 0
[2024-09-17 09:42:19] WARNING[2932264] res_odbc.c: res_odbc: Error SQLConnect=-1 errno=2002 [unixODBC][ma-3.1.12]Can’t connect to MySQL server on 'host…
[2024-09-17 09:42:19] NOTICE[2932264] res_odbc.c: Registered ODBC class ‘pods’ dsn->[asterisk-pods]
[2024-09-17 09:42:19] DEBUG[2932264] res_odbc.c: Connecting db2(0x33f3b00)

@jcolp Seeing there is no response any hints where I can poke around in the code to figure out where the issue may be? Would this be a bug?

We don’t do that timeout. It’s a value we pass in a call we do to UnixODBC[1], and then is outside the scope of Asterisk. You’d be looking at UnixODBC code, and then likely down to the underlying UnixODBC driver.

[1] asterisk/res/res_odbc.c at master · asterisk/asterisk · GitHub

Thanks. So what does connect_timeout in func_odbc.ini do?

It sets a configuration value that we then pass in the above calls. What happens with it is then up to UnixODBC and the rest.