Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
?
Solved

Getting Connection Error after 30 minutes or more (An existing connection was forcibly closed by the remote host)

Posted on 2011-10-05
10
Medium Priority
?
1,148 Views
Last Modified: 2012-05-12
I have  client/server applications written in VB6 that use ODBC to access Firebird databases. The Firebird database server runs on server.

The applications on clients run fine while in use. But When we leave the application after 30 minutes or more the following message is displayed:

"[ODBC Firebird Driver] [Firebird] Unable to complete network request to host "myHostName". Error reading data from the connection. An existing connection was forcibly closed by the remote host."

The user must close the program and reopen it to continue, it does not crash their system. After reopen, the program is back to normal.

Any suggestions on how to fix this?
0
Comment
Question by:setiawan09
  • 3
  • 3
  • 2
  • +1
10 Comments
 
LVL 10

Accepted Solution

by:
ienaxxx earned 1500 total points
ID: 36915694

1. Check the timeout

You should check the timeuot settings at ODBC level as well as at Database level

4. connection pooling

Check that connection pooling is not enabled in the ODBC . look here

3. if nothing works

Then, you should implement a routine that re-connect with the data source without closing the program.
0
 
LVL 10

Expert Comment

by:ienaxxx
ID: 36915696
sry, i mistyped the numbers.... it was 1.2.3...
LOL :-)
0
 
LVL 19

Expert Comment

by:NickUpson
ID: 36915775
is that 30 mins of use or 30 mins of idle? I'm guessing at the idle.

Firebird doesn't have 30 mins as a timeout so I think the problem is in the odbc settings or possible the client operating system
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
LVL 11

Expert Comment

by:kbirecki
ID: 36915822
It could be a timeout on the connection, and that would be the first place to look, but 30 mind of idle seems long for an odbc timeout.  What about checking power settings on both dvds client and (for sure) the server.  Particularly on the NIC's.  By default in Windows clients, the NIC has a power setting to turn  it off automatically. But you should check this and disable it on all servers.
0
 

Author Comment

by:setiawan09
ID: 36919366
Thanks for all your suggest..

The client computer is not idle, just leave the application open and run other programs.  After test to leave the application for more than 1 hours on single machine (as server as well as client), the application still run fine. I think the problem is not the Firebird and ODBC because I use default setting for all.

I'm still on my observation and test various option based on some suggest above.


0
 
LVL 19

Expert Comment

by:NickUpson
ID: 36919708
by idle time I mean the application is open but not being used
0
 
LVL 11

Expert Comment

by:kbirecki
ID: 36920893
Have you checked the power settings on the NIC on server yet?
0
 
LVL 19

Expert Comment

by:NickUpson
ID: 36920958
or tcp timeouts on the server (you don't say what OS)
0
 

Author Closing Comment

by:setiawan09
ID: 36959903
I agree with NickUpson and kbirecki, Firebird doesn't have 30 mins as a timeout and 30 minutes of idle seems long for an odbc timeout. So I'm sure the problem is not on the Firebird and ODBC but on the Network. I have tried to configure and test various option but I got the same result. So I decide to implement a routine to keep the connection alive (open a recordset every 20 minutes).

Thanks
0
 
LVL 11

Expert Comment

by:kbirecki
ID: 36961243
Based on the test you described here:

The client computer is not idle, just leave the application open and run other programs.  After test to leave the application for more than 1 hours on single machine (as server as well as client), the application still run fine. I think the problem is not the Firebird and ODBC because I use default setting for all.

...that's only part of the picture.  This shows the problem is not inherent in the application, but this also may not have been a complete set of tests to identify the root cause.

With the application on your test system setup as client and server, you have eliminated any network component, and that is a good test by itself.  Leaving the suspect application idle for an hour in this scenario and using other applications tells you that the application itself has no problem retaining a good connection.  So reconneting every 20 minutes is only a workaround, and quite possible to fail again without the root cause identified.  So....

If you still want to find the  root cause, you should perform the following tests.  I'm assuming your server is not dedicated to this one and only this one application.  This is important; can you confirm whether it is or not?

Let's call your test Test 1: [Suspect client app *and* server functionality on one system and idle, but client system *not* idle]

Test 2: [Suspect app idle, but client system it is on not idle] - Configure a test system with just the client functionality and another system on the network as the server.  Confirm that the suspect app works.  Like your other test, leave the suspect application idle and use other applications (specifically using apps that hit the network, like accessing files off a server, or the Internet) for more than 30 minutes (or at least once every 10 minutes for 40 minutes.)  After 40+ minutes, check the suspect application.  Is it still working or is it disconnected?

Analysis: If the suspect app is still working, this again confirms that the application is fine, and that something else is causing the disconnect.  If the suspect app fails, then, with this test alone, the problem would seem to be in the application or server.  But your other test has confirmed the app is fine itself when sitting idle for 30+ minutes, so the only new component introduced is the network.  So after these two tests, the problem has to revolve around either the network infrastructure (less likely), client NIC, or the server.  (See note below about the latter.  And network infrastructure has to be *far* down the list of possible causes.)

Test 3: [Suspect app idle, *and* client system it is on idle] - Again, configure a test system with just the client functionality and another system on the network as the server.  Confirm that the suspect app works.  This time, leave the client system completely idle.  After 40+ minutes, check the suspect application.  Is it still working or is it disconnected?

Analysis: If the suspect app is still working, this again confirms that the application is fine, and that something else is causing the disconnect.  (I'm guessing after this test, the app will fail.)  If the suspect app fails, then the problem would seem to be in the client's network connection or the server.  (See note below about the latter.)  In the case of the test failing here, you need to check your client and server network connection.  NIC's are the obvious place to look because some Windows client OS's have default power settings that turn them off after a period of inactivity to save juice.  This would certainly cause your app to behave as you described.  That setting is fine for home users, but in a business, it's not good.  As a matter of practice, that is one of the first things we change when we setup a computer for a user.


Regarding your server, the same settings exist for the NIC on the server and you should check that as well.  If you can reproduce the problem, you're 90% of the way to solving the root cause.  If you haven't identified the root cause (NIC or otherwise) and you just do your workaround in the app, it will fail again in a scenario where the client or server has, for instance, a NIC power down setting of anything less than 20 minutes and you might end up where you are now.
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

How to remove superseded packages in windows w60 or w61 installation media (.wim) or online system to prevent unnecessary space. w60 means Windows Vista or Windows Server 2008. w61 means Windows 7 or Windows Server 2008 R2. There are various …
PRTG Network Monitor lets you monitor your bandwidth usage, so you know who is using up your bandwidth, and what they're using it for.
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.
The viewer will be introduced to the technique of using vectors in C++. The video will cover how to define a vector, store values in the vector and retrieve data from the values stored in the vector.
Suggested Courses

581 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question