Subject Re: FB 1.5 Connection lost problem
Author dirknaudts
> >
> > - Is this at all known to the firebird team ?
> Is "what?" known to the Firebird team?

I meant the "connection closed by remote Host" problem, but as I
understand now, Firebird is just a victim of another problem here at
either NIC or Linux level.

> > - Is FB 1.5 on Linux ruining in production environment anywhere ?
> Ruining? or running? Haven't heard any reports of the former;
> thousands of Fb 1.5 servers are running on Linux, though.

What a typo :-) I meant running

> > - Is this also happening with FB 1.0 on Linux ?
> It's possible that some misconfigured networks wouldn't display
> 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
> at each connected client and listen for a response (much like ping).
> Somehow (as I understand it) this dummy-packet coconut shy was
> (inadvisably) to Linux Superserver, where it interfered with
Linux's own
> keepalive activity to the degree that it caused problems like
> 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
> 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
> and allow the Firebird connections to be kept alive by the network,
> 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
> 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
> properly.

Ok, crystal clear

> > - 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
> 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
> >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
> depends on whether your production environment includes client
> that don't use these old IBO versions. Other connectivity layers
> ignore this bug in the older server versions and let the users live
> the consequences. Fb 1.5 is actually the first version where this
> properly.

Thanks for this info, at least now I have a backdoor if ordering
4.3Aa takes me too long (chain of command to go through)

> > - Would a dum query (select current_date from rdb$database or
> >run on a timer basis hide this problem ?
> Probably; but it's a hack that shouldn't be necessary.

Exactly, and that's how I saw it as well, if all else fails, I'll try
this one.

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

Again valuable info

Thanks Helen, you just saved my week :-)

What I've also learned here is that I really need to buy and read
your book ! Don't know wether all previous is in it, but sure know
there has to be a lot in it that I don't know about yet ...