Skip to Content.
Sympa Menu

freetds - RE: [freetds] timeout

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: 'FreeTDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] timeout
  • Date: Thu, 8 Jan 2004 13:58:53 -0500

> From: Kent Scott [mailto:kscott AT logicalsi.com]
> Sent: January 8, 2004 10:34 AM
>
> Was wondering if someone could give me some direction in
> looking into how
> the timeout on queries work. Quick background info - running
> slackware 9.1, freetds 0.61.2, and php 4.3.3.

Kent,

This issue needs to be addressed. You may have noticed comments in the
code to the effect that some of the timeout logic may be misconceived.

> My biggest problem stems from the fact that if a connection
> is made and
> then lost while trying to run queries (in php) I seem to hang
> indefinitely until the connection comes back.

It fails even in tsql, right?

> [good analysis]
...
> What is supposed to be the difference between
> query_timeout and timeout in connect_info?

There are two timeout settings:

1. How long should we wait before we decide there's no server to connect
to?
2. How long should we let a query run before we give up on it?

By default, afaict, all libraries specify no query timeout i.e., they wait
indefinitely, which is what you're bumping into. You'd like to be able to
specify one.

We have not two but four (!):

$ sed -ne'/tds_connect_info/,/}/p' include/tds.h \
|egrep -i 'time|info'
typedef struct tds_connect_info
TDS_INT connect_timeout;
TDS_INT query_timeout;
TDS_INT longquery_timeout;
int timeout;
} TDSCONNECTINFO;

I'm not sure what "timeout" governs (probably queries, once upon a time,
almost), nor longquery_timeout. I suspect axing the "timeout" member would
be a good first step.

We could use some help with this. I think timeout logic is _at best_
muddled in libtds, partly because the APIs' control over them is quite
varied. For reference, I've enumerated them below. In addition, timeouts
interact with error handling, itself both nontrivial and rather shakily
supported in FreeTDS.

To support all of the permutations correctly looks to me to be a big
undertaking, even once the problem is completely understood. Getting any
one of them to work correctly, given the mix of error handling and socket
programming, won't be easy, even if it's not rocket science. As you can
see, it's a matter of conveying the timeout value from freetds.conf (or the
API) to goodread(), getting goodread() to call the error handler, and
retrying/aborting as appropriate. Piece of cake, for the right guy.

I hope the above is at least a little help. Let me know if you need more.

--jkl

P.S. You're an old-timer, eh?

Appendix ;-)

API functions affecting timeouts
================================

db-lib
Connect timeout:

RETCODE DBSETLTIME (LOGINREC * loginrec, DWORD seconds); (Microsoft)
RETCODE dbsetlogintime(int seconds); (Sybase, FreeTDS)

Query timeout:

RETCODE dbsettime ( INT seconds ); (Microsoft, Sybase, not FreeTDS)

can be overridden by:

RETCODE dbpoll(dbproc, milliseconds, ready_dbproc, return_reason), which we
don't implement.

ct-lib
Connect timeout:

ct_config(), per context. Controlled by connection properties
CS_LOGIN_TIMEOUT, CS_RETRY_COUNT, and CS_LOOP_DELAY. Not mentioned in
FreeTDS's ct-lib code.

Query timeout:

ct_config(), per context. Controlled by connection property CS_TIMEOUT.
Also not mentioned in FreeTDS's ct-lib code.

Timeout handling gets truly hairy in ct-lib, with its asynchronous
programming options.

ODBC
Connect timeout:

SQLSetConnectAttr(), SQL_ATTR_LOGIN_TIMEOUT

Query timeout:

SQLSetConnectAttr(), SQL_ATTR_QUERY_TIMEOUT.

These are supported by the ODBC layer.

-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the original
message. Please note that we do not accept account orders and/or instructions
by e-mail, and therefore will not be responsible for carrying out such orders
and/or instructions.






Archive powered by MHonArc 2.6.24.

Top of Page