Re: One question about setting query timeout.
От | Dave Cramer |
---|---|
Тема | Re: One question about setting query timeout. |
Дата | |
Msg-id | CADK3HHLK+LKtTQCrREakRWzo2Z3+HyCfufp-EzhGNgzOVy8s+A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: One question about setting query timeout. (zhangyuanchao <zhangyuanchao@highgo.com.cn>) |
Ответы |
Re: One question about setting query timeout.
(zhangyuanchao <zhangyuanchao@highgo.com.cn>)
|
Список | pgsql-jdbc |
Hi,
There were some fixes put into the latest version can you check out the snapshot here ?
On Tue, Feb 11, 2014 at 2:01 AM, zhangyuanchao <zhangyuanchao@highgo.com.cn> wrote:
Hi Dave,On 02/10/2014 07:18 PM, Dave Cramer wrote:I think this is a known issues. What version of the driver are you using ?On Sun, Feb 9, 2014 at 10:46 PM, zhangyuanchao <zhangyuanchao@highgo.com.cn> wrote:Hi,
I have a question about setting query timeout by jdbc.
When tested my application with Tomcat7.0 and loadrunner,my tomcat's configure file is like this:
<Resource ......
jdbcInterceptors="QueryTimeoutInterceptor(queryTimeout=600)"
....../>.
After setting like above ,tomcat will call the jdbc's setQueryTimeout function and set the query timeout to 600seconds for each statement.
Next,i start my test with 150 concurrency.After about 10 minutes later,i found the response time was much longer than before.At that moment,i found there were a lot of statement object in the heap memory of the JVM.And the JVM's gc could not clean these objects,because they were referenced by the TimerTask.So i read the source code of the jdbc and Timer class,i found the mainloop function of the Timer calss can cause the problem.This is the code of mainloop function in Timer class and i think the red colour text is that what cause the problem:
private void mainLoop() {
while (true) {
try {
TimerTask task;
boolean taskFired;
synchronized(queue) {
// Wait for queue to become non-empty
while (queue.isEmpty() && newTasksMayBeScheduled)
queue.wait();
if (queue.isEmpty())
break; // Queue is empty and will forever remain; die
// Queue nonempty; look at first evt and do the right thing
long currentTime, executionTime;
task = queue.getMin();
synchronized(task.lock) {
if (task.state == TimerTask.CANCELLED) {
queue.removeMin();
continue; // No action required, poll queue again
}
currentTime = System.currentTimeMillis();
executionTime = task.nextExecutionTime;
if (taskFired = (executionTime<=currentTime)) {
if (task.period == 0) { // Non-repeating, remove
queue.removeMin();
task.state = TimerTask.EXECUTED;
} else { // Repeating task, reschedule
queue.rescheduleMin(
task.period<0 ? currentTime - task.period
: executionTime + task.period);
}
}
}
if (!taskFired) // Task hasn't yet fired; wait
queue.wait(executionTime - currentTime);
}
if (taskFired) // Task fired; run it, holding no locks
task.run();
} catch(InterruptedException e) {
}
}
}
}
So,i want to ask if there is any solution for this problem.
Thanks very much.
Thanks for your response.
The version of driver that i am using is 9.3-1100(the latest version).And i searched some similar problem in the mail list,but i did not get it.I think the reason is : when an statement has been execute finished successfully and the statement cancel the timertask,but the timertask is still in Timer's queue.So the statement is always referenced by the Timer class and it can not be cleaned.
Let me look at the mainloop function of Timer class.The part that is marked red colour can cause the mainloop stop,so the canceled timetask can not be removed from the queue.If i set the query timeout to 600 seconds,the mainloop will wait for about ten minutes.In the ten minutes,there will be more an more statement in the JVM heap.
I think this is what cause the problem,but i don't have some good idea to solve it.Do you have some solution?Thanks a lot.
В списке pgsql-jdbc по дате отправления: