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

Open
firebird-automations opened this issue Jun 2, 2009 · 2 comments

Comments

@firebird-automations
Copy link
Collaborator

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 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.
SQL> connect 'http://xxx.xxx.xxx.xxx:C:\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 '10.0.0.1:C:\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 "172.16.106.122".
-Failed to establish a connection.
-Connection timed out
SQL>

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.

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

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?

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

No branches or pull requests

1 participant