Sorry for that. I changed it 300 seconds. On Wed, Nov 10, 2010 at 2:12 AM, Pid <p...@pidster.com> wrote:
> On 10/11/2010 06:51, sasidhar prabhakar wrote: > > After changing time out value now I am getting this problem > > > > org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a connection, > > pool error Timeout waiting for idle object > > Shall we guess what you set it to? > My guess is "7". Am I right? > > > What else did you change? > > > p > > > > On Tue, Nov 9, 2010 at 5:22 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Sasidhar, > > > > On 11/8/2010 12:31 AM, sasidhar prabhakar wrote: > >>>> On Thu, Nov 4, 2010 at 9:10 PM, Christopher Schultz < > >>>> ch...@christopherschultz.net> wrote: > >>>>> > >>>>> I have found that these exceptions can occur even when there is no > leak. > >>>>> > >>>>> Specifically, if your SQL query takes a long time to run (that is, > more > >>>>> than the ababdonedTimeout), another request to the connection pool > >>>>> complains about the connection and calls it abandoned. > >>>>> > >>>> > >>>> I think your right. Timeout I mentioned 30sec deafault is 300sec. > This > > is > >>>> my context.xml > > > >>>> <?xml version="1.0" encoding="UTF-8"?> > >>>> <Context path="" > > > > > "path" is not allowed in context.xml: remove it. > > > >>>> validationQuery="SELECT * from dual" > > > > SELECT *? Wow. How about "SELECT 1 FROM dual"? > > > >>>> testOnBorrow="true" > >>>> removeAbandoned="true" > >>>> removeAbandonedTimeout="30" > > > > That's a 30-second abandoned timeout. > > > >>>> username="scott" > >>>> password="*******" > > > > "tiger", right? > > > >>>>> Technically speaking, the connection hasn't been leaked, but the > >>>>> connection pool can't really guess the reason why the connection > hasn't > >>>>> been returned. > >>>>> > >>>>> Can you time your queries to see how long they take? Could you post > your > >>>>> <Resource> configuration for your DataSource? > >>>> > >>>> For some queries it took more than 30 seconds, from getting data from > >>>> ip_to_geo table, which has 3 million rows in it. > > > > That could be your problem: you should probably increase your > > removeAbandonedTimeout value to something more appropriate for your > > application. > > > > You might also want a dba to check out your queries and your database > > structure. 3 million rows isn't that much, even for Oracle :) > > > >>>>> Another note: I notice that you are using a DataSource object that > >>>>> survives for the life of the DAO object, and is even created by the > >>>>> object in its constructor. > >>>> > >>>> Every DAO has only one instance for the entire life of application. Is > > this > >>>> correct approach. So Every thread accessing the same datasource object > to > >>>> get connection. > > > > It was just a recommendation which gives you flexibility: your webapp > > (or the container, etc.) has the freedom to discard and completely > > re-build the DataSource for your webapp if you always go to the JNDI > > context to get the DataSource. Otherwise, you will force a webapp > > restart just to get a new DataSource. > > > > -chris > >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > >
