Satheesh Bandaram wrote:
I am not exactly objecting :-) , but it would be nice to add a test case to show the problem the fix is attempting to fix. I suspect the original issue is easy to introduce, but hard to catch.
I have made an attempt, but it is very hard to make a consistent reproduction of the issue. The reason is that when a statement is executed, the timeout value is immediately propagated (through the GenericPreparedStatement) to the StatementContext and the ResultSet. Therefore, the time window where this bug could affect other statements is very small. Also, this bug may only affect statements on different connections, since statements on the same connection may not execute simultaneously. As a result, in order to reproduce this issue, one needs to have the same statement executed simultaneously on many connections on a multi-cpu machine, and even then you'd probably hardly ever see it. By inserting a time-consuming no-op at the right spot in the engine I was able to reproduce it more frequently, but we cannot do that in testing.
While we are on this topic, I noticed SetQueryTimeoutTest test takes around 30-40 minutes on my laptop. On one of our build machines, it actually runs for longer than 2 hours when the test harness actually kills the test. (causing the test to fail everytime) Though this is more of our test machine problem (it is really sloooow), taking 30-40 minutes for one functional test seems too long. Is there anyway the test can be made to run faster?
It now runs in 29 seconds on my machine, I hope that's satisfactory. :)
Satheesh
-- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
