Excessive time taken to return from isql issued CONNECT. [CORE2490] #2903
Submitted by: Jarrett R (wexx)
We noticed the error when developing a software package that connected from FC5 to a remote intrbase server running on windows 2000. They need valid login credentials before they can use the features that go along with reading and writing data to the remote database. We placed default values in for the username, password, dbpath, and dbserver (ip address). Our default IP address just happened to be 10.0.0.1, and then we noticed while testing to make sure the connection failed, that it took anywhere from 5-10 minutes for the connection to return an exception. Granted, at this point we were using IBPP to do the connections however, to determine whether or not it was our fault we decided to go down to the isql level and make sure.
This is what we can do to make it fail consistantly:
fire up isql.. and issue the connect to the typical testing database we use.
Assume that http://xxx.xxx.xxx.xxx is a valid IP, with a host running the server.
Now assume to make it take 5+ minutes to return.
We tried another. lets assume yyy.yyy.yyy.yyy is the address of a machine on the network, NOT running the db server.
I did oodles of searching and even tried altering the firebird.conf file connection timeout from 180 down to 5 seconds. That didn't help even after a restart of the firebird client. I then altered the root directory path and restarted the firebird client, which also didn't do anything to rectify the issue.
When the commands finally return this is what I'm presented with:
what I'm pointing out isn't that something crashes, but that it takes way too long to return with an error and should return immediately if given wrong ip.
The text was updated successfully, but these errors were encountered:
Commented by: Sean Leyne (seanleyne)
The timeout is controlled by TCP settings, it is not really within the engine's control.
To test, try using TELNET to connect to the 3050 port of a host/server which is not running the engine. You will find that it takes the same amount of time as you are experiencing with isql.
Commented by: Jarrett R (wexx)
TELNET returned immediately with an unknown host. When trying to connect to 10.0.0.1:3050. However, the standard rule of 180 seconds are followed when i try to telnet to 10.0.0.1 This rule however is not followed when I attempt a connection using isql and the same IP address. It takes anywhere between 5-7 minutes.
Also, when telnetting to 10.0.0.1 the process can be sent a SIGINT (Cc) . iSql on the other hand cannot be interrupted. We've tried resolving the error of the excess time by setting up a watcher, and a signal handler which interrupts the process and catches the error thrown by the signal handler. This worked for network drops during query execution, however it causes a segfault when the signal is sent to the process while it is trying to connect.
Users shouldn't have to modify any tcp/ip settings in order to have a specific application to timeout properly ... no?