FreeTDS Development Group

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

liam AT inodes.org wrote:
> On Fri, May 06, 2005 at 10:32:51AM +0200, ZIGLIO, Frediano, VF-IT wrote:
> 
> > - timeout. New timeout in TDSSOCKET. I'm very again this. There are
> 
> Perhaps I don't fully understand the intricacies of the TDS protocol
> but the reason I included it is that from my perspective the caller
> may want to wait an hour for a query to finish, but they probably
> don't want to wait an hour to be notified if there is a network
> timeout or error? Are the two ideas mutually exclusive? 

I'm not sure I understand what you mean by a "network timeout".  Which
argument to which function controls that value?  

> Does anything come down the wire when a very long query is being
> executed? I would expect something needs to in order to stop the
> stack from closing the connection?

Once a query is sent to the server, the line is absolutely quiet until the
server answers (if ever).  There is no interim message or heartbeat of any
kind.  

I don't understand why the stack would close the connection merely because
it's idle.  A telnet session can stay up indefinitely without anyone
typing anything.  

> > Sorry, I forgot to add some comments. Why do you add a fixed 60
> > seconds timeout and a 3600 query_timeout? I think that is up to
> > developer if it wants an infinite wait... 
> 
> I think an infinite wait is inappropriate. If the developer wants a very
> 
> long wait then they can set timeout = 86400 or greater in .freetds.conf.

The db-lib docs definitely say the default query timeout is infinite.  I'm
pretty sure the other APIs are similarly specified.  Remember the client
application can set it as appropriate, and can cancel long-running
queries.  

ISTM that a big lock in db-lib is OK.  The db-lib "threading" model, if we
can call it that, is that threads may not share a dbproc.  Mutual
exclusion, then, is required only when inter-process lists are maintained
(e.g.connection_list, as you mentioned).  I haven't been able to look at
your code yet, but do I understand correctly from your postings that we
agree?  

> As to what the default values should be, that's up for discussion.
> 
> > connection close). You removed code to close connection if we are not
> > able to read header... however if we read partially header we go to an
> > invalid state... much better to close connection... Note that goodread
> > do not exit till if read all data... it CANNOT exit on timeout (as it
> > do now... this is the reason timeout test do not works). You can
> > change this behavior however you cannot lose sync with server...
> 
> You know what the right behaviour is here from a TDS protocol
> perspective,  so let's go with your suggestion. If you can produce a
> patch, I'll test it against what my perception of the appropriate
> behaviour should be and hopefully we'll meet in the middle.

The deal is that the server requires the client to read what it sends,
timeout or no.  Even after a cancel packet is sent, for example, the
client is obliged to continue reading any data from the server until it
receives the acknowledgement.  (Similar to XON/XOFF.)  The TDS protocol is
based on TDS packets, and there's no such thing as sending/reading a
partial packet.  If you do, the server will likely drop the connection
instantly.  

Regards, 

--jkl