Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42C2E9C6.6020704@debrunners.com>
Date: Wed, 29 Jun 2005 11:34:46 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
References: <144647292.1118655167897.JavaMail.jira@ajax.apache.org>
 <42B20A92.8030203@debrunners.com> <42BAA8D4.6090100@sun.com>
 <42BB3509.1010101@debrunners.com> <42C2DD8A.9040508@debrunners.com>
In-Reply-To: <42C2DD8A.9040508@debrunners.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Daniel John Debrunner wrote:

> Daniel John Debrunner wrote:
> 
> 
>>Oyvind.Bakksjo@Sun.COM wrote:
>>
>>[on comments about re-use of TimerTasks]
>> write a comment about this in the code in a subsequent
>>
>>
>>>patch (for instance when implementing Statement.cancel), unless anybody
>>>wants me to address this now and submit a new patch.
>>
>>
>>I think delaying the comment is fine.
>>
>>I'm planning to commit this change before the end of this week, assuming
>>all the tests run for me.
> 
> 
> I had to re-run the tests because the patch messed up on one file, but
> now StmtCloseFunTest fails for me with this patch.
> 
> *** Start: StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:08:57 ***
> 2a3
> 
>>Statement Test failed (10)
> 
> 4a6
> 
>>Prepared Statement Test failed
> 
> 7a10
> 
>>Callable Statement Test failed
> 
> Test Failed.
> *** End:   StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:09:05 ***
> 
> I'll look into it, but is anyone else seeing this failure?


This is because the setQueryTimeout used to throw a not implemented
exception, but now succeeds. But in this case the statement is closed so
according to the JDBC spec, all such methods should throw an exception.

Oyvind, do you want me to commit your current patch (I've made the
copyright date changes, and performed the svn adds and propsets) and
then you could fix this problem quickly?

I see now you did say

[comment from Derby-31]
Derbyall has been run with two failures, report attached.
StmtCloseFunTest - hard to tell if it's related to my changes, very
little output from the test about what exactly failed.


The way to investigate this would be to first look at the diff and see
if the output helps in any way. In this case there was a new line of

Statement Test failed (10)

Looking at the test source code, you can then see that the 10 is really
a test case number, this was determined by either searching for 10 in
the source or searching for the complete text 'Statement Test failed (10)'.

Looking at the code for that test case, you can see that the output is
printed if setQueryTimeout succeeds. The fact that this is a call to
setQueryTimeout means that it is related to your change.

Other ways to see which area of a java test is causing the problem is to
see if there is a stack trace being printed. If so the line number
within the test case is a good starting point. Often the stack trace
will be in the '.tmp' output file, but not the '.out' file. Thus it is a
good practice in test code to always print the stack trace for any
unexpected exception.


Dan.