FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2017-10-26 18:11 GMT+01:00 Craig Jackson <cejackson51 AT gmail.com>:
> How long does it stop? By default, a TCP connection can take as 10 minutes
> to time out.
>

When you are just waiting data from the remote end there's no timeout
by default.
If keep alive is active the client generate some activity that than
trigger some timeout.
As Peter was saying can be quite long (2 hours on Windows). On Linux we set 
the
keep alive to about 1 minute to support Azure servers (which are
behind a stateful
firewall).

> Are you specifying timeouts on your freetds calls?
>
> Craig
>

Frediano

> On Thu, Oct 26, 2017 at 4:40 AM, LacaK <lacak AT zoznam.sk> wrote:
>
>>
>> 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!).
>>>>>