FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On December 18, 2006, James K. Lowden wrote:
> tds_goodread() times out on net.c line 406.  It calls the
> tds->query_timeout_func callback.  Already this is broken: control
> should go to _dblib_err_handler and never does.  The application
> installed an error handler with dberrhandle() that is supposed to tell
> libtds what to do with *all* errors, including timeouts.  
> 
> (I know ODBC does not have a client-installable callback.  Does the ODBC
> library install a default one for libtds to call?)  
> 
> True, SYBETIME is not a libtds value.  We need TDSETIME.  It has to be
> passed to the client's callback.  Because the semantics are different
> for each client library, we do this:
> 
>       timeout -> 
>           tds_client_msg(TDSETIME) -> 
>               tds_ctx->err_handler(TDSETIME) ->
>                   [e.g.] dbperror(SYBETIME)
>                       application callback returns INT_CANCEL 
>               returns TDS_INT_CANCEL 
>       close connection 
>       return FAIL
> 
> Cf. dbperror() comments, dblib.c line 7542.
> 
> Each library needs its own tds_ctx->err_handler to interpret libtds
> error numbers.  
> 
> ODBC should have the same interface to libtds but a different interface
> to the application.  It doesn't permit the application to install an
> error handler: 
> 
>       timeout -> 
>               tds_client_msg(TDSETIME) -> 
>               returns TDS_INT_TIMOUT (first time)
>       send cancel packet
>       timeout -> 
>               tds_client_msg(TDSETIME) -> 
>               returns TDS_INT_CANCEL (cancel packet timed out: give up)
>       close connection 
>       return FAIL
> 
> > Mmm... well perhaps dberrhandle callback should be called by
> > dblib_query_timeout...
> 
> No, IMO we should remove tds_socket->query_timeout_func.  We should
> instead use tds_client_msg().  (tds_client_msg() needs work, though.  It
> takes too many parameters.  It should take only a msgno.)
> 
> > In ODBC there is no callbacks, you set a timeout and library
> > automatically cancel query. I don't know however if ODBC close
> > connection automatically when server do not send anything after cancel
> 
> I think it must close the connection and fail the call.  Otherwise the
> client application hangs.  

I began to implement this today.  tds_client_msg is gone, replaced by
tdserror().  That was a technical simplification; no change in behavior
was intended.  Committed.  

I will next remove query_timeout_func, because all errors will be handled
by the library's error handler (superseded by the client's error handler
if the library supports that (which ODBC does not)).  

All errors in libtds should invoke tdserror(), whose return code should
determine whether the function fails, retries, aborts, or attempts to send
a cancel packet.  If the TDS stream becomes desynchronized because the
server stopped responding (and the client stopped retrying), libtds will
close the connection and fail the function, in which case of course the
caller's API function fails and his connection becomes unusable.   

Microsoft and Sybase define dberrhandle differently.  FreeTDS's db-lib
will interpret the installed handler's return code according to whether or
not msdblib compatibility is turned on.  

I am focussing on db-lib for the express purpose of fixing the network
timeout logic.  There may be some breakage in the other libraries (or even
db-lib!) until the dust settles.  You have been warned.  

To reiterate: all three libraries must have a default error handler in
tds_ctx->err_handler, and that handler must handle anything passed to it,
including TDSETIME.  For TDSETIME, CANCEL means close the connection and
fail, CONTINUE means retry, and TIMEOUT means attempt to send a cancel
message. The attempt to send a cancel message is itself subject to timing
out and may be retried.  However, a CANCEL cannot be cancelled; that would
be an error.  

I hope the above, and the reasons for doing this, are clear.  The
terminology is somewhat unhelpful, and the problem is arcane.  I am happy
to answer questions.  

Happy New Year. 

--jkl