At 04:29 AM 16/08/2004 +0000, you wrote:

>Thanks all for jumping in on this one !
>
>At least now I already know I'm not alone on this one :-)
>
>Perhaps some more details might help :
> - Our customer has done the server setup, and gave it a fixed IP
>address
> - I'm a complete Linux newbie
> - In order to do my application tests, I changed static IP address
>from customer Network address to static one in our network range, so
>I could connect to it from our network easily.
> - I didn't edit any host tables whatsoever on neither side of the
>connection.
> - I'm connecting to the server via this static IP address, not
>through it's name.
> - IB EXpert also has the same problems when the connection is
>inactive for some time.
>
>And now some questions :
>
> - Is this at all known to the firebird team ?

Is "what?" known to the Firebird team?

> - Is FB 1.5 on Linux ruining in production environment anywhere ?

Ruining? or running? Haven't heard any reports of the former; many
thousands of Fb 1.5 servers are running on Linux, though.

> - Is this also happening with FB 1.0 on Linux ?

It's possible that some misconfigured networks wouldn't display this
behaviour with Fb 1.0. The reason is that, in older InterBase versions, IB
did its own "keep alive" polling (what Alan McDonald referred to as "a
heartbeat") - every 60 seconds, by default, it would throw a dummy packet
at each connected client and listen for a response (much like ping).

Somehow (as I understand it) this dummy-packet coconut shy was ported
(inadvisably) to Linux Superserver, where it interfered with Linux's own
keepalive activity to the degree that it caused problems like connection
threads that wouldn't die and sometimes crashed the server.

On Windows SS, it was also recognised (rightly or wrongly) as a source of
lost connections and connection pooling strategies that failed when they
should have worked.

So, in Fb 1.5, the dummy packets were disabled, on the understanding that
people would take care to configure keepalive conditions in their networks
and allow the Firebird connections to be kept alive by the network, rather
than the dummy packet hack.

At risk of incurring further network problems, you can reinstate the dummy
packet hack by uncommenting the DummyPacketInterval parameter in
firebird.conf and setting it to a number of seconds, say 60. Don't think
I'm recommending this - on principle, the hack was disabled to get rid of
the problems it caused and to encourage people to configure their networks
properly.

> - Should IBO Version 4.2Ha be ok to connect to FB 1.51

It can; but you need to configure the server to "restore" a bug that exists
in IB and Fb 1.0, that scrambles the order in which parameters return
values in the XSQLDA structure. The bug was fixed in Firebird 1.5. In
firebird.conf you need to uncomment OldParameterOrdering and set it to 1.

> or do I need
>the upgrade ?(for my tests I installed 4.3Aa, but I only own 4.2Ha,
>so I should go into production with that version unless I know I have
>to purchase 4.3Aa.

IBO 4.3Aa is the first version of IBO that can detect that the server is
Firebird 1.5 and make the needed adjustment. Whether you need to upgrade
depends on whether your production environment includes client programs
that don't use these old IBO versions. Other connectivity layers simply
ignore this bug in the older server versions and let the users live with
the consequences. Fb 1.5 is actually the first version where this works
properly.

> - Would a dum query (select current_date from rdb$database or sth)
>run on a timer basis hide this problem ?

Probably; but it's a hack that shouldn't be necessary.

Incidentally, sliding slightly off this immediate topic, on networks where
you're getting timeouts or crashes because of clashes between multiple
NICs, or between an NIC and the operating system's Internet interface
driver, there is a configuration parameter in firebird.conf that allows you
to "fix" the Firebird client/server routing to a single NIC or router
address. Look up RemoteBindAddress.

/heLen