On Nov 14, 2013, at 2:23 AM, Anu Prab <anupr...@gmail.com> wrote: > On Nov 11, 2013, at 12:59 AM, Anu Prab <anupr...@gmail.com> wrote: > >> On Nov 7, 2013, at 11:58 PM, Anu Prab <anupr...@gmail.com> wrote: >> >>>>> I am using Tomcat 7.0.42 and Tomcat jdbc pool. >>> >>>> Just to be perfectly clear, how are you using this? With a <Resource/> >>> tag in your Tomcat >configuration or are you creating the pool in your >>> code? Either way, include the necessary >config or code which shows how >>> you've defined the pool. >>> >>>> The pool configuration is in context.xml. A sample of the config looks >> like >>> this: >>> >>>> <Resource name="jdbc/name" >>>> auth="Container" >>>> type="javax.sql.DataSource" >>>> fairQueue="true" >>>> factory="<customized-factory>" > >>>> timeBetweenEvictionRunsMillis="1800000" > >>>> validationQuery="SELECT 1 from dual" > >>>> validationInterval="30000" > >>>> maxActive="50" > >>>> minIdle="4" > >>>> maxIdle="4" > >>>> maxWait="10000" > >>>> initialSize="4" > >>>> removeAbandonedTimeout="60" > >>>> removeAbandoned="true" > >>>> logAbandoned="false" > >> >>> What factory are you using? It's important to share. Without it we > don't >> know which pool you're using. >> >>> A customized factory which extends org.apache.tomcat.jdbc.pool. >>> DataSourceFactory >>> Few minutes, not sure of the exact timing. Yes, all are 0. >>> >>> Also, what happens when you try to get a connection after the pool count >>> has dropped to 0? >Does it get a new connection? Does it hang waiting? >>> Does it generate any error messages? >>> >>>> Is there any reason why you might be getting disconnected from the >>>> database side or from a >firewall in between your application and the >>>> database? >>> >>> I can still get newer connections even after the count drops to 0. >>> >>> >>> Hi, >>> >>> Also, when I enabled logAbandoned as you suggested, I see this exception >>> after about 17-18 minutes. >>> >>> org.apache.tomcat.jdbc.pool.ConnectionPool abandon >>> WARNING: Connection has been abandoned >>> PooledConnection[oracle.jdbc.driver.T4CConnection@2726965a >>> ]:java.lang.Exception >>> at >>> > org.apache.tomcat.jdbc.pool.ConnectionPool.getThreadDump(ConnectionPool.java:1065) >>> at >>> > org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:707) >>> at >>> > org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:634) >>> at >>> > org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:188) > >> This explains the behavior that you're seeing. It appears that your > connections are being >flagged as abandoned and thus removed from the pool. > >> Take a look at the generated stack trace and see what part of your code is > holding onto the >connection. This could be legitimate, in the case where > you have a long running process (like a >batch job) or it could be a code > error (like you don't have proper try..catch..finally blocks setup >to > close connections). > >> Dan > > Hi, > > The problem that we are facing now is that the connections are showing idle > when they are not being used. When we queried the gv$session table in the > database, we could still find the entry of this inactive/idle connection.
Ok, what does the pool think? Have you looked at the active & idle count there (like with jconsole)? The reason I ask is because based on your configuration you should see some idle connections in the pool. > They are not being "recycled" after the min idle and eviction time had > passed. How are you making this determination? It would be helpful if you could post the active & idle counts from your pool when it's in this state so that we can determine if it should actually be evicting idle threads. Based on the configuration you listed above, I would not expect the pool to evict a connection because it's been idle too long. You have both minIdle and maxIdle set to four and the idle check only runs when you have more than minIdle idle connections in your pool. Because you also have maxIdle set to four I don't think you'll ever have more than four idle connections in your pool. This is because when connections are returned to the pool, the pool checks to see if that connection would push it over maxIdle. If it would then the connection is discarded instead of being returned to the pool. Here's an example: 1.) You start with 4 connections in the pool (that's your initialSize). 2.) The pool cleaner thread runs and no idle check is performed because you don't have more than minIdle idle connections in the pool. 3.) Your application take a connection. 4.) The pool cleaner thread runs again. There is still no idle check is performed, because you don't have more than minIdle idle connections in the pool. 5.) Your application takes four more connections. This causes the pool to create a fifth connection. 6.) The pool cleaner thread runs. Still no idle checks being performed. This time because there are no idle connections. 7.) Your application returns four of the connections. The pool now has four idle connections. 8.) The pool cleaner thread runs. Still no idle checks being performed, you're still at or below minIdle. 9.) Your application returns the fifth connection that was made. Instead of it going pack into the pool, it's discarded because that would push the pool over maxIdle. 10.) The pool cleaner thread runs. Still no idle checks being performed, you're still at or below minIdle. > We think this is happening because the validation query runs and makes the > query "unidle" and hence the eviction does not pick it up. Is it so? I'd say it's unlikely, as the code that validates the connection does not directly update the timestamp on the connection. I'm not going to say it's impossible, because it might be possible for an interceptor to update the timestamp. I haven't looked close enough or done any testing to confirm or deny that though. Your configuration above is not using any interceptors. Is the configuration above still accurate? Have you enabled any interceptors? Dan > Please > help. > > -Anu --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
