Re: FreeTDS and buffering on client side

I cannot reproduce, for me I get an error.
What are you doing in your error/message callback?

Frediano


2017-10-27 13:37 GMT+01:00 LacaK <[email protected]>:
> 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
>>>>> [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
>>>
>>
>
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> https://lists.ibiblio.org/mailman/listinfo/freetds