Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <33500269.1178905275311.JavaMail.jira@brutus>
Date: Fri, 11 May 2007 10:41:15 -0700 (PDT)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-2549) ArrayIndexOutOfBoundsException in
 SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE
In-Reply-To: <3641992.1176708495288.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-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Matrigali updated DERBY-2549:
----------------------------------


notes on the recent patch:
o it looks like your new lines expect 8 space tabs, derby code should either use not indent tabs or should use
    4 space tabs.  
o this level of code should not be doing -- on the page number, it should use the raw store interfaces to move 
    to next and previous pages.  There are a couple of reasons:
    1) even though the current raw store implementation dones have pages for each container laid out from 0 to N,
         future implementations may not.
     2) The get next and get previous interfaces take care of  postioning on the next USER head page -- by doing 
           -- or ++ you may get put on an overflow row page, a raw store internal bit map page, ...

o As you found in your debugging the problem with my previous patch was that the position of the scan was not
    properly maintained in the scan_position (that will teach me to copy/paste code from other parts of system).  
    I think a better fix would be to properly position the scan on the right  row, rather than letting the code get to 
     the postion at next page code path and then reposition backward to the previous page.   

    Scan positions are meant to be maintained by a couple of different means.  While you have a latch on the page
    it is fine to just maintain the slot number as nothing can change out from under you unless you do it.  If you 
    are going to give up the latch on heap scan then the usual way to maintain a scan is by getting the record 
     handl associated with the current slot number, then this can be used to repostion the scan the next trip back.
     I'll post another patch with a suggestion, let me know what you think.  Again I haven't had time to debug it.

     Also it would be good to get a test added to the test suite for this bug, do you plan on doing that?  I think  the
     easiest case would be:
     o create a table with 1 column, smallest datatype possible - say smallint, and largest page size.  It would be good if the
         test case had more than 200 rows that could be moved so it would test visiting the same page more than
         2 times.
     o add enough rows to get a reasonable number of pages - say 10.
     o delete rows leaving at least one row per page, probably easiest if you just delete every row execept each 100th row in the order you inserted them , or something like that. 


> ArrayIndexOutOfBoundsException in SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE
> -------------------------------------------------------------------------
>
>                 Key: DERBY-2549
>                 URL: https://issues.apache.org/jira/browse/DERBY-2549
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.2.2.0
>         Environment: Linux 2.6.x, JRE 1.5.0_b7
>            Reporter: Kurt Huwig
>         Assigned To: Mayuresh Nirhali
>         Attachments: 2549-histogram.png, A2549Test.java, derby-2549-v1.diff, derby2549_mikem.diff, derby2549_v2.diff, DerbyDiskSpaceDiag.java
>
>
> I am doing this in my code:
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('SPONTS','" + "journal".toUpperCase(Locale.US) + "',1,1,1)")
> ("journal" is actually a String-variable, but I replaced it here for easier understanding)
> Sometime - not always - I am getting this exception:
> java.sql.SQLException: The exception 'java.lang.ArrayIndexOutOfBoundsException: 100' was thrown while evaluating an expression. SQLSTATE: XJ001:
> Java exception: '100: java.lang.ArrayIndexOutOfBoundsException'.
>         at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
>         at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
>         at org.apache.derby.client.am.Statement.execute(Unknown Source)
> [...]
> Caused by: org.apache.derby.client.am.SqlException: The exception 'java.lang.ArrayIndexOutOfBoundsException: 100' was thrown while evaluating an expression.
>  SQLSTATE: XJ001: Java exception: '100: java.lang.ArrayIndexOutOfBoundsException'.
>         at org.apache.derby.client.am.Statement.completeExecute(Unknown Source)
>         at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown Source)
>         at org.apache.derby.client.net.NetStatementReply.readExecuteCall(Unknown Source)
>         at org.apache.derby.client.net.StatementReply.readExecuteCall(Unknown Source)
>         at org.apache.derby.client.net.NetStatement.readExecuteCall_(Unknown Source)
>         at org.apache.derby.client.am.Statement.readExecuteCall(Unknown Source)
>         at org.apache.derby.client.am.Statement.flowExecute(Unknown Source)
>         at org.apache.derby.client.am.Statement.executeX(Unknown Source)
>         ... 12 more

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