Re: FreeTDS and buffering on client side

2017-10-31 8:36 GMT+00:00 LacaK <[email protected]>:
> Hello *,
>
> thanks very much for all answers.
>
> I can confirm that:
>
> 1. when I set query timeout by call to dbsettime() then after specified
> number of seconds dbnextrow() returns FAIL and error handler is called with
> 20004 "Read from server failed" (any subsequent call to db-lib function
> returns 20047 "DB-process is dead or not enabled"
>
> 2. when I do not set query timeout and I break TCP connection using "Close
> connection" in TCPView same as in 1 happens
>
> 3. when I set in registry in
> HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters "KeepAliveTime" (and
> restart PC) this value is taken as timeout
>
> 4. when I do not set registry value and wait 2 hours on Windows same as in 1
> happens
>
> Thanks again
>
> -Laco.
>

Just merged (backported) a patch to set keep alive values on Windows
with similar values to
Linux/Unix. Tested with wine.

Still not sure why Linux version you have does not use these settings.
It's working for me.

Frediano

>
>> 2017-10-29 16:38 GMT+00:00 Peter Deacon<[email protected]>:
>>>
>>> On Fri, 27 Oct 2017, LacaK wrote:
>>>
>>>> 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 ...
>>>
>>> Some systems depending on configuration when physical link is lost
>>> actively
>>> close logical interface and associated sockets.  These systems should
>>> return
>>> an error right away.  Some do nothing.
>>>
>>> The difference you are seeing in your testing after waiting longer than a
>>> certain period is a result of server side of the session giving up and
>>> shutting down the TCP session.  Under your test condition the client is
>>> likely to have no idea this has occurred.  All it knows is more data may
>>> or
>>> may not arrive at some undetermined point in the future.  With TCP a
>>> client
>>> can find out in one of three ways:
>>>
>>> 1. Something is transmitted over TCP session such as request for more
>>> data
>>> or app layer keep-alive - at which point lack of connectivity is detected
>>> when transmission timeout expires.
>>>
>>> 2. A TCP layer keep-alive fires off and time outs.  On windows the
>>> default
>>> keep-alive interval is 2 hours.
>>>
>>> 3. Local application timeout such as a configured query timeout?
>>>
>>> Otherwise I would expect the application to sit and wait forever for data
>>> that may never arrive over a server/network/socket that may no longer
>>> exist.
>>> On Windows you are likely looking at 2 hours maximum wait before anything
>>> times out.
>>>
>>> On Windows try waiting 2 hours, using a query timeout or sysinternals
>>> tcpview/process explorer to force close socket of database session from
>>> client process and see if you get an error.
>>>
>>> regards,
>>> Peter
>>>
>> You are right.
>>
>> Linux should have a total keep alive or 1 minute. Weird that is not
>> set that way.
>> I think for Windows is not set so yes, default is 2 hours.
>> You can set query timeout of use interrupt.
>>
>> 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