Subject | Re: Another "connection forcibly closed by the remote host" problem |
---|---|
Author | Adam |
Post date | 2006-06-01T04:16:53Z |
--- In firebird-support@yahoogroups.com, "Scott Moon" <smoon63@...>
wrote:
lost to itself. There would be no switches, network boundaries, VPNs,
Firewalls etc in the way.
To
the network cable and plug it back in and it carries on as if nothing
happenned. I am still not convinced it is related to Firebird. The
Firebird protocol is extremely quiet when nothing is happenning, and
so there is the scope for anything that assumes no traffic = dead
connection to have a false negative here. Run a traffic monitor and
connect to a terminal services session and you will see the
difference. While it is reasonably quiet, it is not silent.
That is why I repeated someone's suggestion to run with a ping. (Of
course that will only work if the ping request reaches the internal
machine.
Perhaps you could write a SQL Script that looks like this (from the
problem workstation):
select 1 from RDB$DATABASE;
Then you can make a batch file that looks something like:
"C:\Program Files\Firebird\Firebird_1_5\bin\isql.exe"
servername:alias -user sysdba -password masterke -i
c:\path\to\script.sql
Run the batch file to confirm it works.
Now add it to the windows scheduled tasks to run every 20 minutes and
see if you can duplicate your problem.
We operate many 2003 servers, though none through VMWare or equiv. We
also support quite a lot of 2K and 2003 servers that are operated by
our customers, and we do not have this issue.
Adam
wrote:
>point.
> --- In firebird-support@yahoogroups.com, "Adam" <s3057043@> wrote:
> >
> > I don't remember if you told your results of openning it on the
> > local machine and leaving it idle?
> >
> > Adam
> >
>
> Once again, thank all of you for your input and help up to this
>on
> I've finally achieved some level of successful testing. Today I
> installed Database Workbench on our production server and ran three
> varying length tests duplicating the steps I had used to crash DBW
> my workstation. On the server, I opened DBW, connected to one of ourSelect
> production DBs, opened an SQL Query window in DBW, ran a simple
> query, then left the connection idle for 60 min, 90 min, and 140min.
> In each case I was able to come back to DBW and view dataimmediately.
> On my workstation, however, the same tests result in our old friendThis proves that from the server machine, the connection is never
> "connection forcibly disconnected by the remote host" error.
>
> Now I'm trying to sort out exactly what, if anything, this proves.
lost to itself. There would be no switches, network boundaries, VPNs,
Firewalls etc in the way.
To
> recap, we are running FB v1.5.3.4870.0 on Windows Server 2003 SESP1,
> running in a virtual server hosted by VMWare ESX on a Linux server.connection
> VMWare support declared their installation innocent today. To this
> point it doesn't seem to make much difference what sort of
> an application uses to connect to FB - we have two older apps thatuse
> BDE, but the same thing happens to DBWorkbench when it is remotelyThese are different protocols. For RDP, you can physically disconnect
> connected. Only connections to Firebird databases are interrupted -
> Remote Desktop sessions are not affected at all. Also, the same
> machine hosts two other virtual servers that act as our ColdFusion
> and GIS servers, and those are not reporting any problems at all.
the network cable and plug it back in and it carries on as if nothing
happenned. I am still not convinced it is related to Firebird. The
Firebird protocol is extremely quiet when nothing is happenning, and
so there is the scope for anything that assumes no traffic = dead
connection to have a false negative here. Run a traffic monitor and
connect to a terminal services session and you will see the
difference. While it is reasonably quiet, it is not silent.
That is why I repeated someone's suggestion to run with a ping. (Of
course that will only work if the ping request reaches the internal
machine.
Perhaps you could write a SQL Script that looks like this (from the
problem workstation):
select 1 from RDB$DATABASE;
Then you can make a batch file that looks something like:
"C:\Program Files\Firebird\Firebird_1_5\bin\isql.exe"
servername:alias -user sysdba -password masterke -i
c:\path\to\script.sql
Run the batch file to confirm it works.
Now add it to the windows scheduled tasks to run every 20 minutes and
see if you can duplicate your problem.
We operate many 2003 servers, though none through VMWare or equiv. We
also support quite a lot of 2K and 2003 servers that are operated by
our customers, and we do not have this issue.
Adam