Subject | Re: Another "connection forcibly closed by the remote host" problem |
---|---|
Author | Scott Moon |
Post date | 2006-06-23T18:40:37Z |
Sorry in advance for the wordy post - but there's a lot to talk about.
And you thought this topic had gone away ;-) I've run a lot of tests
in the last couple of weeks, and have made some headway on this
problem. I still haven't solved it, but it's been narrowed down. A
quick recap:
Environment:
FB SS v1.5.3
Windows Server 2003 Std Edition SP1
Quad Xeon 3.6 GHz Dell server
VMWare ESX Virtual Server running on a Linux OS
VM hosting the Firebird Server is assigned a single CPU, 512 MB RAM, a
10 GB system drive, and a 40 GB data drive.
Problem:
Any connection to the database is broken after remaining idle for more
than 60 minutes, giving the error message "connection forcibly closed
by the remote host". This is 100% reproducable. It occurs on our
in-house client-server applications, off the shelf client-server apps,
as well as ISQL and Database Workbench.
Testing:
I have been able to set up a couple of different test environments,
with interesting results. First we created a separate network,
completely independent of our production system. We set up a VMWare
machine also running 2003 server, but instead of Xeons, this one has
dual Pentiums. In this environment, we did not witness a broken
connection in any of several tests, including a connection left open
and idle for over 12 hours.
Next, on our production server we duplicated the VM that our
production DB is hosted on, and ran the following tests:
1) Against a setup identical to our production VM (FB v1.5.3 with
default settings) - same result - connection was broken.
2) As suggested in other posts, I tried changing the CPU_Affinity_Mask
setting in firebird.conf to various settings. No effect. This
surprised me, as the VM thinks it only has 1 CPU. I would have thought
changing that setting to something other than 1 would prevent firebird
from running properly, but it started and ran regardless of the
setting. I made sure to run several tests that would exclude CPU #1.
3) Uninstalled v1.5.3 and installed v1.0.3. The connection was never
broken, even when left open and idle for 24 hours. Reversed the
process - uninstalled 1.0.3 and reinstalled 1.5.3 - connection broke
after 60 minutes.
4) Replaced 1.5.3 with 1.5.2. Same result - broken connection.
5) Replaced 1.5.2 with 2.0. Same result - broken connection.
Conclusion to this point: Something in the combination of FB v1.5.3 +
Xeon + Win2003 + VMWare is causing this. Since Xeon, Win2003 and
VMWare were all present during the successful 1.0.3 test, that points
to something in v1.5.2 forward. I would like to test earlier versions
of 1.5 as well so I can pin-point the version where the problem
started, but I don't have the install kits and can't find them on
www.firebirdsql.org.
I thank everyone for their help to this point, and certainly welcome
any new insights.
Scott
And you thought this topic had gone away ;-) I've run a lot of tests
in the last couple of weeks, and have made some headway on this
problem. I still haven't solved it, but it's been narrowed down. A
quick recap:
Environment:
FB SS v1.5.3
Windows Server 2003 Std Edition SP1
Quad Xeon 3.6 GHz Dell server
VMWare ESX Virtual Server running on a Linux OS
VM hosting the Firebird Server is assigned a single CPU, 512 MB RAM, a
10 GB system drive, and a 40 GB data drive.
Problem:
Any connection to the database is broken after remaining idle for more
than 60 minutes, giving the error message "connection forcibly closed
by the remote host". This is 100% reproducable. It occurs on our
in-house client-server applications, off the shelf client-server apps,
as well as ISQL and Database Workbench.
Testing:
I have been able to set up a couple of different test environments,
with interesting results. First we created a separate network,
completely independent of our production system. We set up a VMWare
machine also running 2003 server, but instead of Xeons, this one has
dual Pentiums. In this environment, we did not witness a broken
connection in any of several tests, including a connection left open
and idle for over 12 hours.
Next, on our production server we duplicated the VM that our
production DB is hosted on, and ran the following tests:
1) Against a setup identical to our production VM (FB v1.5.3 with
default settings) - same result - connection was broken.
2) As suggested in other posts, I tried changing the CPU_Affinity_Mask
setting in firebird.conf to various settings. No effect. This
surprised me, as the VM thinks it only has 1 CPU. I would have thought
changing that setting to something other than 1 would prevent firebird
from running properly, but it started and ran regardless of the
setting. I made sure to run several tests that would exclude CPU #1.
3) Uninstalled v1.5.3 and installed v1.0.3. The connection was never
broken, even when left open and idle for 24 hours. Reversed the
process - uninstalled 1.0.3 and reinstalled 1.5.3 - connection broke
after 60 minutes.
4) Replaced 1.5.3 with 1.5.2. Same result - broken connection.
5) Replaced 1.5.2 with 2.0. Same result - broken connection.
Conclusion to this point: Something in the combination of FB v1.5.3 +
Xeon + Win2003 + VMWare is causing this. Since Xeon, Win2003 and
VMWare were all present during the successful 1.0.3 test, that points
to something in v1.5.2 forward. I would like to test earlier versions
of 1.5 as well so I can pin-point the version where the problem
started, but I don't have the install kits and can't find them on
www.firebirdsql.org.
I thank everyone for their help to this point, and certainly welcome
any new insights.
Scott