Issue Details (XML | Word | Printable)

Key: CORE-2490
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Jarrett R
Votes: 1
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Excessive time taken to return from isql issued CONNECT.

Created: 02/Jun/09 06:02 PM   Updated: 03/Jun/09 02:34 PM
Component/s: API / Client Library, Engine, ISQL
Affects Version/s: 2.1.1
Fix Version/s: None

Environment: Fedora Core 5. Windows 2000.


 Description  « Hide
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 xxx.xxx.xxx.xxx is a valid IP, with a host running the server.
      SQL> connect '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.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 02/Jun/09 07:13 PM
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.

Jarrett R added a comment - 03/Jun/09 02:34 PM
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?