FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> 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.