Application Server Solutions for Microsoft IIS and ASP.NET
       solutions   products   partners   company   support   downloads         store
JTurbo Self-Help: FAQ
Back to Search >  Back to Search Results

Faq ID 124
Product JTurbo
Category Connection, Connection Pooling, DataSource, Debugging
Question I am getting Communication Link Failure. What does this mean and how can I fix it ?
Answer Communication Link Failure can occur for a variety of reasons.
Among the first things to check are:
  • Make certain you are attempting to connect using the correct hostname, port & database (if the username and password is incorrect the error message would say so).
  • Make certain that your SQL Server is actually up and running.
  • Check your SQL Server logs and/or Event Viewer to see if SQL Server recycled or went down when this error occured. The logs may provide other clues as to what was going on when this error occured.
  • See FAQ #230 for more information

If you are using Connection Pooling then you should know:

When connections in a connection pool get old/stale they can sometimes fail to work with SQL Server complaining about Communication Link Failure or other odd errors. To prevent this, you should periodically clean out stale/unused connections from your pool. If you use JTurbo's Connection Pool implementation, then the ability to do this is already built-in. For example, with PoolManagerDataSource, the default max idle time is 0 which means that connnections are never removed/evicted from the pool, they just hang around forever.
We recommend that you set this to a number of seconds greater than 0 using code sort of like this:

int maxIdleTime = 1800; //30 minutes expressed in seconds.
poolManager.setMaxIdleTime(maxIdleTime);


Once maxIdleTime is > 0, the background thread which cleans up old/stale Connections from the pool (called PropertyCheck Thread) will wake up every 60 seconds by default. This timing can be changed by using code sort of like this:

int propertyCheckSleepTime = 120;
poolManager.setPropertyCycle(propertyCheckSleepTime);

Here are some other troubleshooting ideas to consider:
You may be running out of sockets/ports on the machine where JTurbo is being used. Use a windows tool such as netstat (netstat -a) to look at all of the currently active sockets/ports. Are there many of them? If you reboot the machine, and then use netstat again are there far less active sockets/ports in use? And does that make the problem go away for a while? If so, periodically use netstat and compare its output with previous runs of netstat to see if the # of sockets/ports in use is steadily climbing. When your system is in this state try running your client code from a different machine to see if it works or not. Check your code that is using JTurbo and make sure that you are closing all Connections, Statements, & ResultSets in a finally block:


=========
Connection con = null;
Statement stmt = null;
ResultSet   rs = null;

try
{
   //use JTurbo to interact with the database
}
finally
{
   if(rs != null) try { rs.close(); } catch(Exception ignore) {}
   if(stmt != null) try { stmt.close(); } catch(Exception ignore) {}
   if(con != null) try { con.close(); } catch(Exception ignore) {}

}
=========

If your progam is long-lived (i.e. you start it once and it stays running for a long time, repeatedly getting connections and using them) then not closing things as mentioned above is a definite thing to check.
But also consider how such code is getting its Connection objects.
Is your code simply using DriverManager.getConnection() (Not reusing connections but rather getting a brand new one every time it needs one) ? If so, changing your code to use JTurbo's own built-in connection pooling datasource (PoolManagerDataSource) may be the solution. After you close a (non-pooled) Connection, the OS does not release the socket immediately. It goes into a CLOSE_WAIT state for some time period that the OS determines. Eventually it drops off and its resources (file descriptor) is released to the OS for reuse. But until then it is using up that descriptor. An OS only has so many descriptors to give out at any one time and then they are exhausted.
In that scenario switching your code to get its connections from a db connection pool could be the solution. Doing that is good regardless as it can greatly improve performance of an app that keeps needing connections to the db. But even with a db connection pool you must ensure your code is closing everything.
Doing con.close() on a con that came from a pool does not actually close it, but rather puts it back in the pool for reuse.

You may also find FAQ #21 to be helpful.


It may also be helpful to understand that "Communication Link Failure" is not coming from JTurbo code. JTurbo is receiving that message from SQL Server. JTurbo is then simply wrapping that message into an SQLException and throwing it. A Communication Link Failure problem can occur when using any database client (not just JTurbo). This article may give further clues. It states (among other things) that:
Communication link failure is a mid-stream failure of the connection from client to SQL Server. This typically points to problems with your networking layer, typically networking hardware.

This article explains one case of Communication Link Failure, saying:
The "Address already in use: connect" error is caused by client socket starvation on the machine(s) that [your JDBC driver] is running on. By default Windows does not allow you to set up client connections on ports above 5000. After a socket has been closed, the connection stays in a TIME_WAIT state for another 2 minutes, after which the socket is freed and the address can be reused. If more than 4000 connections (1024-5000) have been made before those ports are freed (after 2 min. in TIME_WAIT), then attempts to open a client socket on a port above 5000 will be rejected by the operating system, which will cause Java to throw "Address already in use: connect". This can be fixed by modifying the Windows registry entry that controls this parameter:

1. Start Registry Editor: Start Menu > Run > Type in "regedit"
2. Locate the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. Right click on the Parameters folder and select New > DWORD Value
4. Name this new key "MaxUserPort"
4. Double click on the "MaxUserPort" key and change the value data to 65534 and select "Decimal" as the base.
5. Restart the machine.
(For more information see Microsoft Knowledge Base Article 196271)
If you see this problem using JTurbo and you are NOT getting your database connections from a JDBC Connection Pool, then before you mess with the registry as described above you should modify your code to get its connections from a Connection Pool instead (JTurbo's built-in PoolManagerDataSource is an excellent choice for this). See the top of this FAQ for more details about using PoolManagerDataSource. This stands a very high chance of completely correcting the issue.



   
company media information terms of use privacy policy contact us