JDBC connection pool size and wait time
We are using RTC 3.0.1, and sometimes we get this error message:
2013-01-25 10:22:14,981 [ ccm: AsynchronousTaskRunner-3] ERROR repository.service.internal.rdb.JDBCConnectionPool - CRJAZ1413E A connection to the database could not be acquired in 3000 ms. This can happen if your server is under very high load, or if your DB server is not powerful enough to quickly process the requests from this server. The primary resolution to this problem is to use a more powerful DB server. If this problem is intermittent, increasing the JDBC Connection Pool Size or JDBC Connection Pool Wait Time properties in the Advanced Properties page might help you avoid the problem in those rare cases.
We solve it by stopping and restarting the WAS instance where RTC is running.
Anyway, our WAS administrators advised us to increase the JDBC connection pool wait time or the JDBC Connection Pool Size in order to avoid it in the future.
Where can this properties be set?
In RTC (i.e. in the teamserver.properties) or in WAS?
Thanks in advance.
|
Accepted answer
These properties can be set in the Advanced Properties page of the application's Server Administration -> Server section. If you click on Database Connection under the Configuration section on the left side, you will see those settings in the second section of properties listed.
The default values are: JDBC Connection Pool Size 128 JDBC Connection Pool Wait Time 3000 With an admin privileged user ID, you can change those values and click SAVE. I believe you then have to restart the server for these changes to take affect. Since JTS, CCM, and QM all have their own repositories and independent database connections (and settings), this operation must be done for each of these applications independently. You may only need to make the change for the one repository connection that is spitting out the errors. For RTC it may be in the JTS repository or for the CCM repository and you need to figure out which connection is in trouble. If you notice the error message that you copied actually specified that the ccm application was the source of the error so that would be the settings that need to be adjusted. Luca Martinucci selected this answer as the correct answer
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Oddly, our CLM environment hit this today (4.0.1) and we think it might have been due to database interaction with Tivoli Storage Manager. We send DB2 logs to TSM.
Does anything like that occur for your environment around the time you quote above ?
For all I know, people here is not using TSM