Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Excessive time taken to return from isql issued CONNECT. [CORE2490] #2903

firebird-issue-importer opened this issue Jun 2, 2009 · 2 comments


Copy link

@firebird-issue-importer firebird-issue-importer commented Jun 2, 2009

Submitted by: Jarrett R (wexx)

Votes: 1

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, 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 is a valid IP, with a host running the server.
SQL> connect '\INTRBASE\bin\GA' user 'sysdba' password 'masterkey';
That connects fine, all good. Takes about 1 second.

Now assume to make it take 5+ minutes to return.
SQL> connect '\INTRBASE\bin\GA' user 'sysdba' password 'masterkey';
This is one case.

We tried another. lets assume yyy.yyy.yyy.yyy is the address of a machine on the network, NOT running the db server.
SQL> connect 'yyy.yyy.yyy.yyy:C:\INTRBASE\bin\GA' user 'sysdba' password 'masterkey';
This still returns with an exception after approximately 5+ minutes.

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:
Statement failed, SQLCODE = -902
Unable to complete network request to host "".
-Failed to establish a connection.
-Connection timed out

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.
If this bug is my fault, let me know please point me to how to fix it, close it out do whatever. All I ask is for some information on how to fix it.

Copy link

@firebird-issue-importer firebird-issue-importer commented Jun 2, 2009

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.

Copy link

@firebird-issue-importer firebird-issue-importer commented Jun 3, 2009

Commented by: Jarrett R (wexx)

TELNET returned immediately with an unknown host. When trying to connect to However, the standard rule of 180 seconds are followed when i try to telnet to 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 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant