FreeTDS Development Group

[Godefroid Chapelle <gotcha AT bubblenet.be>]

Lowden, James K wrote:

Thanks for this long answer !!

> > From: Godefroid Chapelle
> > Sent: Wednesday, December 06, 2006 4:22 AM
> >
> > if ... the network connection to the database server gets lost,
> > the following queries do hang forever without complaining.
> >
> > I have looked both at FreeTDS and pymssql code to find out if there
> > was any way to setup the chain so that we could be warned by FreeTDS
> > that a network error happened (instead of hanging).  
>
> I have studied this question carefully and come to a simple conclusion:
> Not yet.  
>
> A db-lib program (and I don't know if pymssql is one) sets its query
> timeout with dbsettime(). 
> It sets its error handler with dberrhandle().

pymssql is db-lib under Linux and OSX at least.

> Whenever db-lib begins to wait for a response from the server, it sets
> that timeout.  When it expires, it calls  the error handler with
> SYBETIME. 
> The handler can choose to return INT_CONTINUE, telling db-lib
> to wait for another timeout period.  Or the handler can choose to return
> INT_CANCEL, telling db-lib to give up.  Both vendors say that INT_CANCEL
> causes the connection to be broken.  
>
> What src/tds/net.c::tds_goodread() should do on receipt of INT_CANCEL
> from the error handler:
>
> 1.  Close the socket.
> 2.  Mark the connection DEAD.
> 3.  Return failure.  
>
> What src/tds/net.c::tds_goodread() does on receipt of INT_CANCEL:
>
> 1.  Defeat the timeout, in src/tds/query.c::tds_send_cancel()
> 2.  Send a cancel packet. 
> 3.  Wait for an acknowledgement from the server until tcp/ip times out.

Further, I think that the current code in tds_goodread has no way out of 
the loop even when cancelling.

> Sometimes the OS may return an error when the cancel packet is sent.  If
> not, though, #3 may take a long time, as in hours, while tcp/ip retries
> the packets.  If the network is restored in the meanwhile, the
> connection will be OK when control is returned to the application.  But
> probably the user gave up and killed it first.   
>
> Besides the error handler, the application is supposed to have another
> function it can use for timeout purposes: dbdataready().  Unfortunately,
> it's not implemented in FreeTDS.  
>
> Now that I understand the problem (I believe), it's possible to fix it.
> Please don't hold your breath, though.  It will take me awhile to do it
> unless someone sends me a patch.  And then the Python folks have to make
> sure their code takes advantage of our improvement.  And they have to be
> using db-lib, because I'm not sure how ct-lib and ODBC will be affected.
>
>
> --jkl

--
Godefroid Chapelle (aka __gotcha)- BubbleNet  http://bubblenet.be