Re: BindException (Address already in use) when connecting to MSSQL

From: John C. Bollinger (jobollin_at_indiana.edu)
Date: 07/06/04 

Date: Tue, 06 Jul 2004 13:37:22 -0500

Tage V. Madsen wrote:

> I'm experiencing a problem with JDBC and MSSQL 2000, now and again
> DriverManager.getConnection() throws a java.net.BindException, with
> this message:
>
> TCP/IP connection failed to host:java.net.BindException: Address
> already in use: connect
> url:jdbc:JSQLConnect://localhost:1433/database=DBx/
>
> I've boiled the problem down to an example - listed below, after
> connecting approx. 3960 times the exception is thrown - on my 3 Ghz
> PC, on slower ones it works, so it must be timing-related...

If the diagnostic message is to be accepted as a reasonably accurate
description of the failure then it would seem to indicate a problem in
the driver, Java class library, or in Windows network stack. However,
it may well be that it is a problem that is not triggered in reasonable
use scenarios. Your code creates many connections to the same local
address and closes them again, all as fast as it can. This does not
model any reasonable use scenario; indeed if it persisted long enough
this test would constitute a DOS attack.

My best guess is that you are running into a system limit on the number
of open file descriptors. Invoking close() on your Connections will
cause their sockets to eventually be closed, but it may not force them
to close immediately. This would be a performance feature. However, if
you keep opening new sockets without giving the existing, no longer
needed ones a chance to close then you will eventually run into a file
descriptor limit.

> To verify that MSSQL is working, I've created a similar app in
> VC++/ODBC, and there it works fine - I can connect 100000 times
> without problems.

That's nice, but not very relevant.

> I'm using JNetDirect's JDBC driver, but I've also tried the MS driver,
> same behaviour. The use of DriverManager instead of a (pooled)
> DataSource is merely for simplicity, the behaviour is, again, the
> same, either way.

I don't believe that you will see this behavior with a DataSource that
actually uses a connection pool if you ensure that the pool has a
reasonable maximum size. Indeed, even a size cap oughtn't to be
necessary in the single-threaded test scenario you present. Beware,
however, of DataSource implementations that may just wrap DriverManager
without providing pooling. Don't assume that a DataSource automatically
uses a pool.

John Bollinger
jobollin@indiana.edu

Relevant Pages

  • Commons DBCP pooling problem
    ... I am using Commons DBCP to pool my sqlserver database connections. ... Class for retrieving datasource: ... ResultSet myResults = null; ...
    (microsoft.public.sqlserver.jdbcdriver)
  • Re: SQL Server 2005 JDBC Driver - JBoss configuration with a data sour
    ... I got this configuration file to work in JBoss. ... <!-- This will be run before a managed connection is removed from the pool ... > this new driver but am wondering how I actually set my datasource up to ...
    (microsoft.public.sqlserver.jdbcdriver)
  • Re: How to Change datasource, username and password on batch import
    ... You will probably find that the wizard generated copies of connections and you probably only have around 4 actual connections. ... I want to be able to store the DTS package into a file so ... give the datasource, user and password to the DTS for ALL of my ...
    (microsoft.public.sqlserver.dts)
  • RE: process failed
    ... it looks like the datasource specified can't be found. ... Be sure the ODBC ... > - Initiating transaction in Database 'Tutorial' ... > - Processing Dimension 'Scenario' failed. ...
    (microsoft.public.sqlserver.olap)
  • database login
    ... i've setup my report to use project data>current connections as my ...
    (microsoft.public.vb.crystal)