You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by TomohitoNakayama <to...@basil.ocn.ne.jp> on 2005/10/06 18:14:44 UTC
closing ByteArrayInputStream problem (Re: [jira] Commented: (DERBY-596) jdbcapi/resultsetStream.java fails in DerbyNetClient Framework)
Hello.
I think we can ignore test which corresponds to differece of 8a9 .
I found that InputStream was not closed .
This is not correct in spec of java.sql.ResultSet .
However, the InputStream was exactly ByteArrayInputStream as shown in error message .
>> > FAIL - stream was not closed after a get*() call. class java.io.ByteArrayInputStream
And Java API spec says that closing ByteArrayInputStream has no effect .
http://java.sun.com/j2se/1.4.2/docs/api/java/io/ByteArrayInputStream.html
Closing a ByteArrayInputStream has no effect.
The methods in this class can be called after the stream has been closed without generating an IOException.
Then the behavior of the program does not differ , wheter InputStream was closed or not.
I think no problem here .
// There remains a suspicion that it may be bad that ByteArrayInputStream is used there , in view of performance ....
// It is too heavy item in this issue. I leave it as suspicion found n DERBY-596 now .
Best regards .
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Tomohito Nakayama (JIRA)" <de...@db.apache.org>
To: <de...@db.apache.org>
Sent: Tuesday, October 04, 2005 11:00 PM
Subject: [jira] Commented: (DERBY-596) jdbcapi/resultsetStream.java fails in DerbyNetClient Framework
> [ http://issues.apache.org/jira/browse/DERBY-596?page=comments#action_12331273 ]
>
> Tomohito Nakayama commented on DERBY-596:
> -----------------------------------------
>
> Next code is where difference of 8a9 was happended .
>
> org.apache.derbyTesting.functionTests.tests.jdbcapi.resultsetStream: L166
> InputStream is = rs.getBinaryStream(1);
> <snip>
> System.out.println("second columns is " + rs.getInt(2));
>
> System.out.println("FAILS DUE TO BUG 5710");
> try {
> is.read();
> System.out.println("FAIL - stream was not closed after a get*() call. " + is.getClass());
> break;
> } catch (IOException ioe) {
> // yes, stream should be closed
> }
>
>
> According to Note at next url , InputStream "is" must be closed implicitly when rs.getInt(2) was evaluatted .
> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.html#getBinaryStream(int)
>
> However InputStream "is" was not closed and "is.read()" was unsuccessfully successed .
> At last, message of "FAIL - stream was not closed after a get*() call. class java.io.ByteArrayInputStream " was generated .
>
>> jdbcapi/resultsetStream.java fails in DerbyNetClient Framework
>> ---------------------------------------------------------------
>>
>> Key: DERBY-596
>> URL: http://issues.apache.org/jira/browse/DERBY-596
>> Project: Derby
>> Type: Bug
>> Components: Network Server, Test, Network Client
>> Versions: 10.2.0.0
>> Reporter: Tomohito Nakayama
>> Assignee: Tomohito Nakayama
>
>>
>> Working in DERBY-525, I found that jdbcapi/resultsetStream.java , which was originally excluded from DerbyNetClient Framework,
>> fails, if added to.
>> Next is resultsetStream.diff :
>> ------------------ Java Information ------------------
>> Java Version: 1.4.2_08
>> Java Vendor: Sun Microsystems Inc.
>> Java home: /usr/local/j2sdk1.4.2_08/jre
>> Java classpath: /home/naka/ProgramDev/derby/trunk/jars/sane/derby.jar
>> :/home/naka/ProgramDev/derby/trunk/jars/sane/derbyclient.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbytools.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbynet.jar:
>> /usr/local/share/java/db2jcc/lib/db2jcc.jar:
>> /usr/local/share/java/db2jcc/lib/db2jcc_license_c.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyTesting.jar:
>> /home/naka/ProgramDev/derby/trunk/tools/java/jakarta-oro-2.0.8.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_de_DE.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_es.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_fr.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_it.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_ja_JP.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_ko_KR.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_pt_BR.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_zh_CN.jar:
>> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_zh_TW.jar
>> OS name: Linux
>> OS architecture: i386
>> OS version: 2.4.27-2-386
>> Java user name: naka
>> Java user home: /home/naka
>> Java user dir: /home/naka/ProgramDev/testDerby/20051001
>> java.specification.name: Java Platform API Specification
>> java.specification.version: 1.4
>> --------- Derby Information --------
>> JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
>> [/home/naka/ProgramDev/derby/trunk/jars/sane/derby.jar] 10.2.0.0 alpha - (292740M)
>> [/home/naka/ProgramDev/derby/trunk/jars/sane/derbyclient.jar] 10.2.0.0 alpha - (292740M)
>> [/home/naka/ProgramDev/derby/trunk/jars/sane/derbytools.jar] 10.2.0.0 alpha - (292740M)
>> [/home/naka/ProgramDev/derby/trunk/jars/sane/derbynet.jar] 10.2.0.0 alpha - (292740M)
>> ------------------------------------------------------
>> ----------------- Locale Information -----------------
>> Current Locale : [English/United States [en_US]]
>> Found support for locale: [de_DE]
>> version: 10.2.0.0 alpha - (292740M)
>> Found support for locale: [es]
>> version: 10.2.0.0 alpha - (292740M)
>> Found support for locale: [fr]
>> version: 10.2.0.0 alpha - (292740M)
>> Found support for locale: [it]
>> version: 10.2.0.0 alpha - (292740M)
>> Found support for locale: [ja_JP]
>> version: 10.2.0.0 alpha - (292740M)
>> Found support for locale: [ko_KR]
>> version: 10.2.0.0 alpha - (292740M)
>> Found support for locale: [pt_BR]
>> version: 10.2.0.0 alpha - (292740M)
>> Found support for locale: [zh_CN]
>> version: 10.2.0.0 alpha - (292740M)
>> Found support for locale: [zh_TW]
>> version: 10.2.0.0 alpha - (292740M)
>> ------------------------------------------------------
>> Framework: DerbyNetClient
>> *** Start: resultsetStream jdk1.4.2_08 DerbyNetClient 2005-10-02 13:56:27 ***
>> 8a9
>> > FAIL - stream was not closed after a get*() call. class java.io.ByteArrayInputStream
>> 12 del
>> < EXPECTED SQLSTATE(XSDA4): An unexpected exception was thrown
>> 13 del
>> < EXPECTED SQLSTATE(XJ001): Java exception: 'Input stream held less data than requested length.: java.io.IOException'.
>> 14 del
>> < EXPECTED SQLSTATE(XSDA4): An unexpected exception was thrown
>> 15 del
>> < EXPECTED SQLSTATE(XJ001): Java exception: 'Input stream held less data than requested length.: java.io.IOException'.
>> 15a13,14
>> > EXPECTED SQLSTATE(null): End of Stream prematurely reached while reading InputStream, parameter #2. Remaining data has been
>> > padded with 0x0.
>> > EXPECTED SQLSTATE(null): The specified size of the InputStream, parameter #2, is less than the actual InputStream length
>> Test Failed.
>> *** End: resultsetStream jdk1.4.2_08 DerbyNetClient 2005-10-02 13:56:49 ***
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.9/118 - Release Date: 2005/10/03
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.11/121 - Release Date: 2005/10/06
Re: closing ByteArrayInputStream problem (Re: [jira] Commented: (DERBY-596) jdbcapi/resultsetStream.java fails in DerbyNetClient Framework)
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I feel uneasy about performance problem around ByteArrayInputStream , which is not Stream but exactly ByteArray ,
as much as compatibility problem .
I want to solve compatibility problem which you mentioned ,same time when we solve performance problem .
I think these information should be posted to JIRA .
Best regards.
.... and good night! It is midnight 1:45 at Tokyo :)
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Daniel John Debrunner" <dj...@debrunners.com>
To: "Derby Development" <de...@db.apache.org>
Sent: Friday, October 07, 2005 1:23 AM
Subject: Re: closing ByteArrayInputStream problem (Re: [jira] Commented: (DERBY-596) jdbcapi/resultsetStream.java fails in
DerbyNetClient Framework)
> TomohitoNakayama wrote:
>
>> Hello.
>>
>> I think we can ignore test which corresponds to differece of 8a9 .
>>
>> I found that InputStream was not closed .
>> This is not correct in spec of java.sql.ResultSet .
>>
>> However, the InputStream was exactly ByteArrayInputStream as shown in
>> error message .
>>
>>>> > FAIL - stream was not closed after a get*() call. class
>>>> java.io.ByteArrayInputStream
>>
>>
>> And Java API spec says that closing ByteArrayInputStream has no effect .
>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ByteArrayInputStream.html
>> Closing a ByteArrayInputStream has no effect.
>> The methods in this class can be called after the stream has been
>> closed without generating an IOException.
>>
>> Then the behavior of the program does not differ , wheter InputStream
>> was closed or not.
>>
>> I think no problem here .
>
> I think there is a problem, the JDBC spec says the stream is closed
> after a getXXX, and in this case, because the close has no affect it
> does not appear closed to the application. Thus the application may
> continue to use the stream when it shouldn't and that behaviour
> might/will change in the future, or may not be consistent now depending
> on the stream implementation returned by the driver.
>
> I seem to remember that embedded worked around this by
> wrapping/extending ByteArrayInputStream so that the close did close the
> stream.
>
> Dan.
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.11/121 - Release Date: 2005/10/06
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.11/121 - Release Date: 2005/10/06
Re: closing ByteArrayInputStream problem (Re: [jira] Commented: (DERBY-596)
jdbcapi/resultsetStream.java fails in DerbyNetClient Framework)
Posted by Daniel John Debrunner <dj...@debrunners.com>.
TomohitoNakayama wrote:
> Hello.
>
> I think we can ignore test which corresponds to differece of 8a9 .
>
> I found that InputStream was not closed .
> This is not correct in spec of java.sql.ResultSet .
>
> However, the InputStream was exactly ByteArrayInputStream as shown in
> error message .
>
>>> > FAIL - stream was not closed after a get*() call. class
>>> java.io.ByteArrayInputStream
>
>
> And Java API spec says that closing ByteArrayInputStream has no effect .
> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ByteArrayInputStream.html
> Closing a ByteArrayInputStream has no effect.
> The methods in this class can be called after the stream has been
> closed without generating an IOException.
>
> Then the behavior of the program does not differ , wheter InputStream
> was closed or not.
>
> I think no problem here .
I think there is a problem, the JDBC spec says the stream is closed
after a getXXX, and in this case, because the close has no affect it
does not appear closed to the application. Thus the application may
continue to use the stream when it shouldn't and that behaviour
might/will change in the future, or may not be consistent now depending
on the stream implementation returned by the driver.
I seem to remember that embedded worked around this by
wrapping/extending ByteArrayInputStream so that the close did close the
stream.
Dan.