Skip to Content.
Sympa Menu

freetds - Re: [freetds] Time out issue

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Xu Behoneo" <behoneox AT hotmail.com>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] Time out issue
  • Date: Thu, 30 Nov 2006 14:53:07 +0800

Hi, jkl

Of your points, sorry for that I'm not familiar with db-lib and ctlib.
I'm using ODBC API to query a MSSQL database with FreeTDS as the driver, the timeout issue was brought when I calling SQLExecDirect and at such time the server is down, the SQLExecDirect will be blocked. I think maybe I need to set some timeout attributes, I look into the ODBC API documents, and find SQLSetConnectAttr can set timeout for a dbc handle, and SQLSetStmtAttr can set timeout for a statement handle. I set both, but the SQLExecDirect still block, I look into the freetds code and find that, I'm not sure whether this timeout should be apply to the driver. As you have said, maybe my application need to take some special operation for this case.

Thanks,
Behoneo


From: "James K. Lowden" <jklowden AT freetds.org>
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: Thu, 30 Nov 2006 00:54:23 -0500

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/
>
>
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com




Archive powered by MHonArc 2.6.24.

Top of Page