FreeTDS Development Group

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

Xu Behoneo wrote:
> 
> I understand that the client needs to receive a cancel reply from
> server,  but assuming that there is a network failure or server down, it
> will block  until everything works fine. I think this isn't a good
> behavior, of course  return immediately isn't appropriate also. Maybe we
> can still specify the  second select a timeout, and if it timeout also,
> then we can return.

Perhaps.  You'd need to point me to some relevant documentation, though.  

We don't make up library behavior; we try to conform to specifications. 
For db-lib, there are two:

1.  dbsetlogintime(), how long to wait for an answer to a login request
2.  dbsettime(), how long to wait for a query to execute.  

You're using ODBC.  If you can point out a timeout value that the FreeTDS
ODBC driver isn't honoring correctly -- i.e., according to the ODBC
specification -- I'm sure we'd want to look at it.  

The idea, I believe, is that the timeouts apply to server operations, not
network behavior.  The client may connect to a remote port where no server
is responding.  When to stop waiting for a reply is up to the application.
 How long to wait for a query to execute is, too.  Network timeouts --
such as how many times a packet is resent and how long to wait for an
acknowledgement -- are controlled by tcp/ip timeouts that are built into
the network stack.  

Specifically, dbsettime() does *not* apply to cancel messages.
(http://manuals.sybase.com:80/onlinebooks/group-cnarc/cng1110e/dblib/@Gen
eric__BookTextView/39238;pt=9393#X)  That's consistent: it's expected that
the server can respond in timely manner to the cancel message.   

If the network goes down when the cancel message is sent, tcp/ip will
eventually return some kind of error[1].  That will be propagated up the
FreeTDS layers, resulting in the API function returning a FAIL status.  

Sorry for such a long message.  You raised an important point, and I
wanted to address it fully.  

--jkl

[1] Depending on exactly what happened and whose tcp/ip implementation
you're using, the retries could go on for hours, which might seem like
forever but actually isn't.  


> >From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
> >Reply-To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
> >To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
> >Subject: Re: [freetds] Time out issue
> >Date: Wed, 29 Nov 2006 08:48:50 +0100
> >
> > >
> > > Hi, all
> > >
> > > When I use the FreeTDS with unixODBC, I have a timeout
> > > problem, I'm not sure whether this is a bug.
> > >
> > > The issue is in the "tds_goodread" function(src/tds/net.c),
> > > when the "select" function returns because of timeout, the
> > > "len" variable will be set to 0, and it will go into the "if"
> > > section, in that, a query timeout function will be called,
> > > without dblib, this function will always be
> > > "query_timeout_cancel" function(src/odbc/odbc.c), and it set
> > > the timeout of the tds socket to 0 and returns
> > > "TDS_INT_CANCEL", so that in the former "if" section, a
> > > cancel packet is sent, but it still in the loop and call
> > > select again, but at this time, the timeout value is 0 and
> > > select will wait forever.
> > >
> > > I think after called the "tds_send_cancel" call, it should
> > > return immediately.
> > >
> > > Thanks,
> > > Benheng Xu
> >
> >No, the behavior is correct. Assuming you send a query that take a lot
> >of time, when timeout is reached you send cancel request and you have
> >to wait for DONE with cancel reply from server. You cannot return
> >immediately cause you break server syncro so you would end up in an
> >inconsistent state.
> >
> >Frediano
> >
> >_______________________________________________
> >FreeTDS mailing list
> >FreeTDS AT lists.ibiblio.org
> >http://lists.ibiblio.org/mailman/listinfo/freetds
> 
> _________________________________________________________________
> Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn/  
> 
>