Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <31187349.1177628896244.JavaMail.jira@brutus>
Date: Thu, 26 Apr 2007 16:08:16 -0700 (PDT)
From: "Kathey Marsden (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2381) ParameterMappingTest fails due to
 ArrayIndexOutOfBoundsException  executing a procedure
In-Reply-To: <4487382.1172698971291.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492150 ] 

Kathey Marsden commented on DERBY-2381:
---------------------------------------

The number cast  seems to work ok for everything but BigDecimal as there is no Number.bigDecimalValue(), but I keep thinking it is somehow wrong to be changing the type of the output parameter value, when returning it to the client. I think there might be cases where the output parameter value might get changed when being converted.  I think we need to be able to send the parameter in as one type and out as another, so that when sending output parameters, we switch on the actual type of the parameter, not on the type sent by client.  


> ParameterMappingTest fails due to ArrayIndexOutOfBoundsException  executing a procedure
> ---------------------------------------------------------------------------------------
>
>                 Key: DERBY-2381
>                 URL: https://issues.apache.org/jira/browse/DERBY-2381
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.3.0.0
>            Reporter: Kathey Marsden
>         Assigned To: Kathey Marsden
>         Attachments: d2381.java
>
>
> The test ParameterMappingTest fails due to a connection reset error during tearDown.  Commenting out the teardown actions I see that the real cause of the connection reset is an ArrayIndexOutOfBoundsException executing a callable statement.  I have not narrowed it down more than this.  Currently the test runs only for embedded. It should be reenabled for client once this bug is fixed.  Below is the stack trace:
> java.lang.ArrayIndexOutOfBoundsException
> 	at java.lang.System.arraycopy(Native Method)
> 	at org.apache.derby.client.net.Reply.shiftBuffer(Reply.java:107)
> 	at org.apache.derby.client.net.Reply.ensureSpaceInBufferForFill(Reply.java:153)
> 	at org.apache.derby.client.net.Reply.fill(Reply.java:165)
> 	at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java(Compiled Code))
> 	at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317)
> 	at org.apache.derby.client.net.Reply.peekCodePoint(Reply.java:1008)
> 	at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:324)
> 	at org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:105)
> 	at org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75)
> 	at org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:176)
> 	at org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1464)
> 	at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2151)
> 	at org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1571)
> 	at org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:1556)
> 	at org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.testParameterMapping(ParameterMappingTest.java:487)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
> 	at java.lang.reflect.Method.invoke(Method.java:391)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.