Skip to Content.
Sympa Menu

freetds - Re: [freetds] new network timeout code

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] new network timeout code
  • Date: Mon, 8 Jan 2007 14:29:15 +0100

>
> James K. Lowden wrote:
> > net.c::tds_select().
> >
> > It's not called by anything yet, so it can't do any harm.
>
> No longer. net.c has been redone in terms of tds_select.
> Cancel messages
> are now subject to the same timeouts as queries.
> tds_goodwrite looks a
> lot like tds_goodread. Timeout conditions invoke the client library's
> error handler.
>

Looking at tds_goodread/tds_goodwrite it seems that moving tdserror call
in tds_select would help reducing code.

> All I know for sure is that all but one unit test passed for
> ct-lib and
> db-lib. ct-lib's "connect_fail" test failed. I'm not
> surprised, because
> I didn't modify the ct-lib error handling yet.
>
> We have tests that cancel queries, but I don't think we have
> anything that
> specifically tests timeout handling. So I think tds_select()
> works when
> everything's OK. I'm not yet convinced it works with something goes
> wrong.
>
> I didn't compile the ODBC driver. I'm not set up for it at
> the moment.
> Do we have an ODBC timeout unit test?
>

Yes, odbc contains a timeout test.

> I don't have a way to test tds7_get_instance_port(), either. I don't
> think it should call tdserror because TDSETIME isn't appropriate and
> neither is anything else. It's not subject to a login
> timeout or a query
> timeout. Probably the code should (and does) silently try a
> few times and
> return failure if it doesn't get an answer. Ultimately that becomes a
> "could not connect" message.
>

if you don't know the port to connect this become (correctly) a connect
problem. But looking at login.c I see no tdserror call if port is
invalid

if (!IS_TDS50(tds) && !tds_dstr_isempty(&connection->instance_name))
connection->port =
tds7_get_instance_port(tds_dstr_cstr(&connection->ip_addr),
tds_dstr_cstr(&connection->instance_name));

if (connection->port < 1) {
tdsdump_log(TDS_DBG_ERROR, "invalid port number\n");
return TDS_FAIL;
}

> I'll look at ct-lib next, to fix up its error-handler
> interface to libtds.
> Then I'll work on a unit test or two. I'm hoping to have
> that done in a
> few days. Then I hope folks will start to use the new snapshots and
> provide feedback. Patches welcome too!
>
> Many thanks to Frediano and Peter Deacon for their advice.
>

Trying to fix odbc.c I noted that we don't make any difference between
msg_handler and err_handler however in libTDS they are handled in a very
different way (msg_handler result is ignored). Another problem (at least
in ODBC) is that we copy server name from first handler call however for
client messages server is always "OpenClient".

freddy77





Archive powered by MHonArc 2.6.24.

Top of Page