FreeTDS Development Group

[Jon Pounder <pounder AT inline.net>]

actually I don't think that will work for odbc.

odbc supports cancel as well, but it only makes sense when the connection
is polled to see if the execution is complete. for "blocking" calls to odbc
it makes no sense, and this is where the timeouts come in (to escape from
calls that would block forever due to a network or server problem) ie: the
cancel would never be acknowledged under those conditions.

I believe the way it is setup, if you simply initialize timeouts to 0 they
disappear and it will block forever waiting for input.


At 12:36 PM 6/23/00 -0400, you wrote:
>On Fri, 23 Jun 2000, Jon Pounder wrote:
>
>> Hi,
>> 
>> I have not been able to reach Jeff myself in a while, so I'll answer.
>> 
>> Yes in general, when any sort of timeout occurs the odbc layer would return
>> an error, so other than getting more error details from the odbc layer, the
>> application would presumably close the socket connection shortly thereafter
>> without attempting any more reads. So as far as I see it the timeout
>> occuring mid packet would corrupt the stream, but likely it occurred in the
>> first place since there was a network problem already (assuming timeouts
>> are set to realistic values). Then when the application closes the
>> connection no further reads on the corrupted stream would occur after that.
>> 
>> Does this make sense ?
>
>Yes it makes sense, however I have an, err, more appropriate proposal.
>
>I currently have cancels working fairly acceptably and will hopefully
>be rolling the changes in sometime soon.  The way I would recommend
>doing this is to have the ODBC layer install a general timeout handler
>(as opposed to just the longquery handler that is there right now).
>Then, when this handler is called it can issue a tds_cancel(TDS_CANCEL_ATTN)
>which will cancel the current query, causing whatever tds call
>is currently waiting for network I/O to return TDS_CANCELED.
>This will time the query out, leaving the connection in a usable
>state.
>
>I am not sure if this will deal with your networking failure scenario
>as it expects the server to eventually acknowledge the cancel request.
>
>-scott
>
>> 
>> 
>> At 08:33 AM 6/23/00 -0400, you wrote:
>> >
>> >As mentioned before, I have been in the process of imlementing cancels
>> >in the TDS layer.  As part of this effort I had to re-implement most
>> >of the network calls (I actually implemented a little network layer).
>> >Everything is working dandy except that I a trying to roll the
>> >timeout changes back in that were made by Jeff (the comments don't say
>> >Jeff's last name or e-mail address). 
>> >
>> >While I am doing it I discovered something that concerns me.
>> >
>> >It looks like the way the timeouts work is that if tds->timeout
>> >is set, then any call to read or write to the network (all calls
>> >to tds_read_packet() or tds_write_packet()) will return if 
>> >tds->timeout seconds has expired without reading an entire packet.
>> >
>> >The problem is that if the timeout period is reached while in
>> >the middle of reading a packet--which is unlikely but possible,
>> >the packet stream is then effectively corrupted.  The next call
>> >to tds_net_read() will read the first 8 bytes off the network
>> >thinking that it is a packet header when it is really the
>> >last half of the last packet.
>> >
>> >So, in either case, timeouts are likely to break things.
>> >
>> >Also, if the timeout period is reached and no bytes have been
>> >read yet, all calls to tds_get_<datatype> will return 0, which
>> >will screw up the parsing of the TDS stream.
>> >
>> >So, my question: what are timeouts _supposed_ to do? I suspect
>> >that they are intended to cancel the current operation, but I 
>> >am not sure.
>> >
>> >-scott
>> >
>> >--
>> >Scott C. Gray <gray AT voicenet.com>     "my keybard is brken"
>> >       http://www.voicenet.com/~gray/sqsh.html
>
>-scott
>
>--
>Scott C. Gray <gray AT voicenet.com>     "my keybard is brken"
>       http://www.voicenet.com/~gray/sqsh.html
>
>
>---
>You are currently subscribed to freetds as: pounder AT inline.net
>To unsubscribe, forward this message to
$subst('Email.Unsub')
>
>

        Jon Pounder,   Development Engineer
        Inline Internet Systems
        pounder AT inline.net Jon AT Pounder.com

        Web Tools Engineered for Success
        http://www.inline.net
        http://www.ihtml.com