Re: FreeTDS and buffering on client side

>> 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
>>> [email protected]
>>> https://lists.ibiblio.org/mailman/listinfo/freetds
>>>
>> _______________________________________________
>> FreeTDS mailing list
>> [email protected]
>> https://lists.ibiblio.org/mailman/listinfo/freetds
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> https://lists.ibiblio.org/mailman/listinfo/freetds
>