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

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?
setiawan09Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ienaxxxCommented:

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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ienaxxxCommented:
sry, i mistyped the numbers.... it was 1.2.3...
LOL :-)
0
Nick UpsonPrincipal Operations EngineerCommented:
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
Simple Misconfiguration =Network Vulnerability

In this technical webinar, AlgoSec will present several examples of common misconfigurations; including a basic device change, business application connectivity changes, and data center migrations. Learn best practices to protect your business from attack.

kbireckiCommented:
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
setiawan09Author Commented:
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
Nick UpsonPrincipal Operations EngineerCommented:
by idle time I mean the application is open but not being used
0
kbireckiCommented:
Have you checked the power settings on the NIC on server yet?
0
Nick UpsonPrincipal Operations EngineerCommented:
or tcp timeouts on the server (you don't say what OS)
0
setiawan09Author Commented:
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
kbireckiCommented:
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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Network Analysis

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.