FreeTDS Development Group

[LacaK <lacak AT zoznam.sk>]

Same behavior also on Windows (current master) and on Linux (Ubuntu with 
installed libsybdb5 package)
Once network cable is unpluged loop freezes and FAIL is not returned 
from dbnextrow()

So I think, that it is reproducible case ...

L.


> > > Thank you very much Frediano,
> > >
> > > now , when I increase number of rows in table I can reproduce network
> > > failure.
> > >
> > > But behavior is other than I have expected.
> > >
> > > I was expecting, that dbnextrow() will return FAIL, but it seems, 
> > > that call
> > > to dbnextrow() never returns ... it freezes somewhere in dblib.dll
> > > (I can not debug more because I use dblib.dll from Pascal program)
> > >
> > > Is it expected behavior?
> > >
> > > L.
> > No, should return an error.
> > TDSDUMP could help.
> I have recompiled dblib from todays git master to ensure that problem 
> persist.
> And yes persists.
> When rows are reading in loop and I unplug network cable loop stops.
> When I plug-in cable in few seconds loop continues and rows are returned.
> But when I unplug for longer time say 1 minute loop does not continue 
> and program freezes.
>
> Then I must force end of program. Here are last lines in tdsdump 
> (nothing special IMO):
> Whole dump has 265MB (as I transfer big rows with TEXT fields)
>
> 10:29:32.620 (dblib.c:2064):dbnextrow(032F9D10)
> 10:29:32.620 (dblib.c:2070):dbnextrow() dbresults_state = 2 
> (_DB_RES_RESULTSET_ROWS)
> 10:29:32.620 (token.c:532):tds_process_tokens(032F14A8, 015BFDE0, 
> 00000000, 0x1508)
> 10:29:32.620 (util.c:165):Changed query state from PENDING to READING
> 10:29:32.620 (token.c:547):processing result tokens.  marker is 
> d2(NBC_ROW)
> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 0
> 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0
> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4
> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 1
> 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0
> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4
> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 2
> 10:29:32.620 (data.c:740):tds_get_data: type 39, varint size 2
> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4
> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 3
> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 4
> 10:29:32.620 (data.c:740):tds_get_data: type 35, varint size 4
> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 5000
> 10:29:32.620 (packet.c:640):Received packet
> ...follows binary dump of packet
>
> Thank you
> L.
> > > > > Hi *,
> > > > >
> > > > > I would like to ask how FreeTDS performs buffering on client side.
> > > > > I use dblib as my client library (I do not set there DBBUFFER using
> > > > > "dbsetopt")
> > > > >
> > > > > I am trying simulate network failure in such way:
> > > > > 1. connect to MS SQL Server using dbopen()
> > > > > 2. I send SQL select using dbcmd(), dbsqlexec()
> > > > > 3. then I call dbresults()
> > > > > 4. here I pause program and unplug network cable to simulate network
> > > > > error
> > > > > 5. next I process rows in loop calling dbnextrow()
> > > > >
> > > > > Strange thing is that I can perform step 5 also when network cable is
> > > > > unpluged. So I have suspection, that all rows from select are already
> > > > > somewhere on client side. Probably handled already by underlaying 
> > > > > libtds
> > > > > ?
> > > > >
> > > > > What is going to happen? Why I can still read rows when there is 
> > > > > already
> > > > > broken network connection ?
> > > > > Thanks
> > > > >
> > > > > -Laco.
> > > > There are a lot of caching in between.
> > > > The server execute the query and starts sending back results.
> > > > Probably the results you are expecting are already sent by the server
> > > > when you disconnect the cable and are in the tcp socket buffer ready
> > > > to be parsed from your program. Try to return 1000000 rows and at
> > > > some point the program will fail (unless connection is really fast and
> > > > network buffer is big enough!).
> > > >
> > > > Frediano
> > > > _______________________________________________
> > > > FreeTDS mailing list
> > > > FreeTDS AT lists.ibiblio.org
> > > > https://lists.ibiblio.org/mailman/listinfo/freetds
> > > _______________________________________________
> > > FreeTDS mailing list
> > > FreeTDS AT lists.ibiblio.org
> > > https://lists.ibiblio.org/mailman/listinfo/freetds
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > https://lists.ibiblio.org/mailman/listinfo/freetds