Skip to Content.
Sympa Menu

freetds - Re: [freetds] timeout

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] timeout
  • Date: Thu, 8 Jan 2004 20:48:45 -0500

On Thu, 08 Jan 2004, Kent Scott <kscott AT logicalsi.com> wrote:
> I suspect axing the "timeout" member would
> >be a good first step.
...
> The connection timeout (connect_info->connect_timeout) seems to have the
>
> most implementation in place. There seems to be 3 ways to set its value
> - tds_parse_conf_section(), dbsetlogintime(), and tds_set_timeouts().
> The first of those 3 is obvious - my guess from the other 2 was that
> they were set up to be called either by the programmer in the code or by
> any other language (such as PHP) during an initialization routine?

tds_set_timeouts() is a self-labelled hack. IMHO we should write
tds_config() -- based on ct_config() -- to manage connection options, and
get the client libraries out of the business of writing to the data
structures. But that's not a necessary precondition to making query
timeouts possible.

dbsetlogintime() is a login timeout, not a query timeout. If you will,
it's managing a template value: when a new connection is opened, its login
timeout value is taken from that set with dbsetlogintime(). This is a
published db-lib function. It might be called by PHP, depending on how
PHP was configured.

tds_parse_conf_section() should IMHO also not write to the structure, but
call my putative tds_config().

> I did notice that PHP does attempt to call dbsettime()
> except that it isn't implemented yet. The only part that was throwing me
>
> off was that tds_parse_conf_section() was looking for and setting
> timeout and not query_timeout.

Right. I don't see much point in adding query_timeout to freetds.conf. I
suppose we could, but why? The docs all say that the default is no
timeout, so every application has to be written to set the timeout itself
via the API.

I think it's more important to write dbsettime() and perhaps its libtds
counterpart. You're using the mssql extension, I take it.

> Would it make sense then to implement dbsettime() to
> act like dbsetlogintime() for query_timeout as well as to parse
> freetds.conf for the value?

If by "act like dbsetlogintime()" you mean, "make dbsettime() do what
Sybase says it should do", yes. Else I don't understand the question.
:-)

> I do believe that goodread() needs to be slightly modified for the
> query_timeout to work. It goes in to a do..while loop if the timeout is
> set and exits if the time passes (this part works fine). However, the
> very next thing it does after exiting the loop is to call READSOCKET()
> where it still hangs. We would need to test if the socket is dead or
> something and return instead.

That's definitely the harder part. There's a long chain of events that
has to respect the timeout value and react to the timeout.

> As for error handling - I was hoping to avoid looking in to that -
> although I do need it. I will start trying to get at least a little
> familiar with it. Just give me your thoughts.

It's totally necessary, but you have a shortcut at your disposal. The
general solution requires rewriting our error handling and discarding
tds_client_msg(). I've written about that at some length before, and
won't repeat myself here, for your sake. The shortcut, for better or
worse, is to *use* tds_client_msg(). It needs a little modfication, IIRC,
to make sure it passes the error handler's return code back to the caller,
because that's how the handler tells the caller -- goodread(), in this
case -- whether to retry or give up.

ct-lib and db-lib have different notions of how to react to a timeout, of
whether or not the connection can continue to be used, or is marked dead.
If you want to just get the db-lib semantics working, that's fine. I'd be
really enthusiastic if you embrace a more general approach.

In any case, goodread() has to call the error handler to decide what to do
next. If you re-read the error handling documentation with a Through the
Looking Glass eye, you'll see by inference what the library has to do. If
you want to understand it, it's a good idea to look at the ct-lib docs,
too.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page