Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F219039.9050405@christopherschultz.net>
Date: Thu, 26 Jan 2012 12:41:13 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat 6.0.35-SocketException: Too many open files  issue with
References: <1327219288.36843.YahooMailNeo@web112008.mail.gq1.yahoo.com>
 <4F1C6193.5010206@christopherschultz.net>
 <1327274292.57660.YahooMailNeo@web112004.mail.gq1.yahoo.com>
 <4F1D8210.3080007@christopherschultz.net>
 <1327553604.70946.YahooMailNeo@web112016.mail.gq1.yahoo.com>
In-Reply-To: <1327553604.70946.YahooMailNeo@web112016.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

G,

On 1/25/12 11:53 PM, gnath wrote:
> As you have suggested, i started collecting the thread dumps

Thread dumps will set you free. Well, not really. Instead, they will
tell you where your webapp is breaking, which usually means more work
for you. But at least the hard part is done: finding out what's breaking.

> when it happened again and we saw some kind of DBCP Connection pool
> issues leading to 'Too Many open files' issue.

That will definitely do it.

> So we decided to replace the commons DBCP with tomcat-jdbc.jar
> (with same configuration properties).

Why?

> After this change, it seemed for few hours but started seeing in
> the logs where the Connection Pool jar could not give any 
> connections and seems to be all the connections are busy. So we
> went ahead and added a configuration property
> 'removeAbandoned=true' in our Datasource configuration.

I would go back to DBCP unless you think you need to switch for some
reason.

I suspect you are leaking database connections and don't have a
suitable timeout for removal of "lost" database connections (or maybe
didn't have that set up in the first place).

You really need to enable "logAbandoned" so you can find out where
your connection leaks are, and fix them. In development, set
maxActive="1" and leave it there, forever. Also, set
logAbandoned="true" and always run like that in development. Running
like that in production isn't a bad idea, either.

> We are still watching the performance and the server behavior
> after these changes. Will keep you posted on how things will turn
> out or if i see any further issues.

I suspect you are still leaking connections, but your pool is now
silently cleaning-up after the mess your webapp is making. Instrument
your pool. Fix your leaks.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8hkDkACgkQ9CaO5/Lv0PCxFgCgs+EiV/CNjmCNekeDwKHgnNtZ
5LYAoKZUkIAJOK0eItkoHBF3wScK9lQf
=AyL4
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org