ConnectTimeout to be made configurable

[praveend]

Hi Daniel

I see that the connectTimeOut interval is been set to 5 seconds, with a TODO for making it configurable.

We were trying to connect to DB2 server behind tight firewalls and started hitting a connect time out failure. Could you comment out setting the timeout until it is made configurable?

Thanks

Praveen

[wankdanker]

Hey Praveen,

I did one better, I hope. I implemented the ability to change the connectTimeout at run-time. Since you have a situation where you can test it, I figured I might as well make it happen. It's hard for me to test a connection timeout because everything on my local network accepts connections so quickly. :)

I released v0.5.24 on my fork. You can set the connectTimeout like so:

var db = require('odbc')({ connectTimeout : 60 });

or

var odbc = require('odbc');
var db = new odbc.Database({ connectTimeout : 42 });

If the connectTimeout is 0 then a connection timeout won't be set.

[wankdanker]

Install with npm install git://github.com/wankdanker/node-odbc.git#v0.5

Let me know if it works for you and we can close this issue.

Thanks,

Dan

[wankdanker]

Assuming fixed.

[rossipedia]

Curious, I'm running into an issue where this property seems to be ignored if the server is not accepting connections at all. I usually run SQL Server in a VM on my OSX machine, and use a connectTimeout value of 2.

If the VM is not running at all, then calls to open can take upwards of 75 seconds or more. Here's my test script and some sample output:

var odbc = require('odbc');
var db = odbc({connectTimeout: 1});

console.log('Connecting with connectTimeout: 2');
console.time('connect');
db.open(process.env.CONNECTION_STRING, function(err) {
  console.log('connect callback running');
  if (err) console.error(err);
  else console.log('connected!');
  if (db.connected) db.close();
  console.timeEnd('connect');
});

Output:

Connecting with connectTimeout: 2
connect callback running
Error: [unixODBC][FreeTDS][SQL Server]Unable to connect to data source
connect: 76009ms

[wankdanker]

That is interesting. Is there anyway to test this with isql or other tool? Have you ever seen this work as expected? Maybe my initial fix for it didn't actually work.

We use SQLSetConnectAttr with SQL_ATTR_LOGIN_TIMEOUT to enable the timeout. I wonder if this does not include TCP connection or DNS lookup time.

[wankdanker]

Ahh. Looks like there is a separate attribute for connection timeout: SQL_ATTR_CONNECTION_TIMEOUT (http://msdn.microsoft.com/en-us/library/ms713605(v=vs.85).aspx)

We should implement both the loginTimeout and connectTimeout.

[wankdanker]

I should be able to get this fixed in a few minutes.

[wankdanker]

@rossipedia, could you test with odbc installed from npm install wankdanker/node-odbc#fix-connectTimeout?

If that works, I'll push out v0.6.5.

[rossipedia]

Connecting with connectTimeout: 2
connect callback running
ERROR: Error: [unixODBC][FreeTDS][SQL Server]Unable to connect to data source
connect: 8ms

That's much, much better, thanks for the prompt fix!

EDIT Although, I might be having an issue now that the server's up. Testing...

[rossipedia]

Yeah it's still bugged. Now I can't actually connect to the server even though it's running.

[wankdanker]

Are you getting any errors or anything? I can't replicate.

[rossipedia]

Let me put together a minimum-code replication

[rossipedia]

Okay so I'm having trouble replicating this in isolation, and it's a travel day for me. I'll try to pin down what's going on in my existing codebase either tonight or tomorrow.

[wankdanker]

OK. I'll hold off on merging this until we get this figured out. Safe travels.

[wankdanker]

FYI: I am randomly encountering an assertion error in the FreeTDS driver when specifying a value for connectTimeout which in turn sets SQL_ATTR_CONNECTION_TIMEOUT:

node: net.c:350: tds_select: Assertion `timeout_seconds >= 0' failed.
Aborted (core dumped)

Sometimes it does assert and some times it does not. May be a race condition some[where|how]. I'm not quite sure how though. We are using a mutex around the SQLSetConnectAttr and SQLDriverConnect calls.

I do not have this issue with the SQL Server Native Client 11.0 driver and connectTimeout > 0.