Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of cjderham@gmail.com designates
 209.85.223.178 as permitted sender)
MIME-Version: 1.0
Reply-To: chris@derham.me.uk
Sender: cjderham@gmail.com
In-Reply-To: 
 <CAH1VVmWOqGFEKt_SOfkBj+LhHxNR+kxhN5XPHVhY7sENDKt_wg@mail.gmail.com>
References: 
 <CAH1VVmWdM50pWZiC2ns5ieEGe4Pz0MTKxXYFH6qqF+H3ABR5=Q@mail.gmail.com>
 <89D58E36-EFFE-43E6-A77B-DEC396895935@vmware.com>
 <CAH1VVmWOqGFEKt_SOfkBj+LhHxNR+kxhN5XPHVhY7sENDKt_wg@mail.gmail.com>
From: chris derham <chris@derham.me.uk>
Date: Tue, 2 Apr 2013 07:56:18 -0300
Message-ID: 
 <CAG6aRdV2gCnpg1vtvksE_5ju5c2q++VU834h4TDBiqCYyVi-TQ@mail.gmail.com>
Subject: Re: Analyzing Connection Pool Errors/Leaks
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

> OK, I'll have to investigate the DB setting more thoroughly. The maximum
> sessions and processes in Oracle are higher than we were using for the test
> though (several hundred).

We hit a similar situation a year ago. Essentailly Oracle has a TNS
listener process that accepts connections. This is responsible for
counting connections and preventing any new ones when the limit is
hit. The counting only occurs on a background thread every x minutes,
hence if you have a high turnover of connections, you can exceed the
limit. Even if your app correctly returns all connections, the TNS
listener will not "see" the returned connections, and hence hit the
error above. For our situation we were able to just bump up the
connections allowed to the db. This may or may not help in your case

HTH

Chris

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