To:
informix-list@iiug.org (
informix-list@iiug.org)
Fernando, Andreas,
we use Solaris 10 and as you said the interval is 2H. The command to show is /usr/sbin/ndd -get /dev/tcp tcp_keepalive_interval. You will see milliseconds. In our case 7200000.
Yes, we'll try it. k=1 is part of the comma separated options list in fifth column of sqlhosts.
Thanks,
Reinhard Habichtsberg
Dienstleistungsverantwortlicher IT-Rechenzentrum
Solaris- und Datenbanksysteme
Abrechnungszentrum Emmendingen
Tel.: 07641/9201-203
-----Ursprüngliche Nachricht-----
Von:
ids-bounces@iiug.org [mailto:
ids-bounces@iiug.org] Im Auftrag von Fernando Nunes
Gesendet: Dienstag, 5. September 2017 17:17
An:
ids@iiug.org
Betreff: Re: keep-alive in sqlhosts [39810]
It will solve the issue (unless the firewall is configured to ignore it, but I've never seen any case of that).
HOWEVER... the option in Informix side "asks" the OS to send the probes.
When (with which interval), the answer timeout etc. is entirely the OS responsability... and in many situations the defaults are around 2H, and most situations I've seen the firewalls "kill" the connections after 1H...
if you find yourself into this situation, the feeling you'll get it that it didn't work... when in fact it's just misconfiguration.
You should check the OS documentation on how to configure the keep alive functionality... I've been involved in linux and hp-ux in the past... but if you need assistance, please tell us your OS.
Note that after you change SQLHOSTS you need to at least restart the listener (if your Informix version has this functionality). Checking if the option is in effect can be trivial (lsof) in most operating systems, but is nearly a nightmare on Linux...
one option is to compile and load a kernel module.... but I always have the feeling there's another option, which I never remember... maybe some obscure option of netstat... another option would be to sniff the trafic...
Regards.
On Tue, Sep 5, 2017 at 12:59 PM, Habichtsberg, Reinhard <
RHabichtsberg@arz-emmendingen.de> wrote:
Hi all,
we have the problem that longer lasting remote client sessions on
informix databases are interrupted by the firewalls, particulary when
no packets were sent. It's possible to configure the port on the
firewall to extend the time before the connection is interrupted. The disadvantage is that you never know if the time you choose is long
enough or if you found all database-server ports.
We found a parameter which can be set in the sqlhosts file of the
server, if I understand aright.
From http://www-01.ibm.com/support/docview.wss?uid=swg21160988
To enable the keep-alive option for an Informix database server TCP
port, specify k=1 in the fifth column of the related line of the
server in the sqlhosts file. The following table is a summary of
possible setting of the keep-alive option in an IBM Informix server sqlhosts file and its results.
k setting in the options field Result
k=0 Disables keep-alive feature: this means the local TCP driver does
not check whether a connection is active. For example, from a PC, if
you make a connection to an IBM Informix database server, and then
switch off the PC, then netstat -a and onstat -u shows the TCP and
database network connection are still established. The TCP connection
is never terminated until stopping and restarting the Informix server.
k=1 Enables the keep-alive feature
My question: Does this setting solve the issue? Or can it cause
unexpected side-effects.
Thanks,
Reinhard Habichtsberg
Dienstleistungsverantwortlicher IT-Rechenzentrum
Solaris- und Datenbanksysteme
Abrechnungszentrum Emmendingen
Tel.: 07641/9201-203
************************************************************ *******************
Forum Note: Use "Reply" to post a response in the discussion forum.
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)