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 "Thomas Nielsen (JIRA)" <ji...@apache.org> on 2008/05/21 09:45:55 UTC
[jira] Issue Comment Edited: (DERBY-3219) Group by query with many
aggregate columns and case statements fails with: ERROR XSDA7: Restore of a
serializable or SQLData object of class , attempted to read more data than
was originally stored
[ https://issues.apache.org/jira/browse/DERBY-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598579#action_12598579 ]
thomanie edited comment on DERBY-3219 at 5/21/08 12:43 AM:
-----------------------------------------------------------------
Running the repro on an unpatched head of trunk, on solaris10 x86 with sun jdk 1.6.0_04, with -Dderby.debug.true=SortTuning gives:
---
DEBUG SortTuning OUTPUT: sortBufferMax = 1024 estimatedRows = 30 estimatedRowSize = 0 defaultSortBufferMax = 1024
DEBUG SortTuning OUTPUT: Growing sortBuffer dynamically, current sortBuffer capacity= 1023 estimatedMemoryUsed = 8264424 currentTotalMemory = 92667904 currentFreeMemory = 79419968 numcolumn = 4 real per row memory = 8078
---
Seems that the currentTotalMemory and currentFreeMemory are the only real differences from your platform.
Limiting the memory to 16M or 32M triggers the reported error on my machine too:
java -Dderby.debug.true=SortTuning -Xmx32M -Xms32M repro
The SortTuning in this case is
---
DEBUG SortTuning OUTPUT: sortBufferMax = 1024 estimatedRows = 30 estimatedRowSize = 0 defaultSortBufferMax = 1024
DEBUG SortTuning OUTPUT: Growing sortBuffer dynamically, current sortBuffer capacity= 1023 estimatedMemoryUsed = 7836080 currentTotalMemory = 32374784 currentFreeMemory = 19119984 numcolumn = 4 real per row memory = 7659
---
Like Knut says -Xmx only specifies the maximum allowed but it will start out lower than that. Also -Xms defined the minimum, so with min=max and increasing *both* these values you should get the scenario I think you expect :)
was (Author: thomanie):
Running the repro on an unpatched head of trunk, on solaris10 x86 with sun jdk 1.6.0_04, with -Dderby.debug.true=SortTuning gives:
---
DEBUG SortTuning OUTPUT: sortBufferMax = 1024 estimatedRows = 30 estimatedRowSize = 0 defaultSortBufferMax = 1024
DEBUG SortTuning OUTPUT: Growing sortBuffer dynamically, current sortBuffer capacity= 1023 estimatedMemoryUsed = 8264424 currentTotalMemory = 92667904 currentFreeMemory = 79419968 numcolumn = 4 real per row memory = 8078
---
Seems that the currentTotalMemory and currentFreeMemory are the only real differences from your platform.
Limiting the memory to 16M or 32M triggers the reported error on my machine too:
java -Dderby.debug.true=SortTuning -Xmx16M -Xms16M repro
The SortTuning in this case is
---
DEBUG SortTuning OUTPUT: sortBufferMax = 1024 estimatedRows = 30 estimatedRowSize = 0 defaultSortBufferMax = 1024
DEBUG SortTuning OUTPUT: Growing sortBuffer dynamically, current sortBuffer capacity= 1023 estimatedMemoryUsed = 7836080 currentTotalMemory = 32374784 currentFreeMemory = 19119984 numcolumn = 4 real per row memory = 7659
---
Like Knut says -Xmx only specifies the maximum allowed but it will start out lower than that. Also -Xms defined the minimum, so with min=max and increasing *both* these values you should get the scenario I think you expect :)
> Group by query with many aggregate columns and case statements fails with: ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was originally stored
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3219
> URL: https://issues.apache.org/jira/browse/DERBY-3219
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.1.4
> Reporter: Stan Bradbury
> Assignee: Bryan Pendleton
> Attachments: maxminPatch.diff, patchWithTest.diff, pivotView.zip, repro.java, testWithMemControls.diff
>
>
> using the attached database (v10.3) - " select * from pivotview " fails with the stack trace below. A view (pivotview_ok) created on a subset of the columns in pivotview executes fine. Adding one column back into pivotview_ok causes failures most of the time. See attached for view definitions.
> 2007-11-21 00:58:49.421 GMT Thread[main,5,main] (XID = 2734422), (SESSIONID = 0), (DATABASE = pivotview), (DRDAID = null), Failed Statement is: select * from pivotview
> ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was originally stored
> at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> at org.apache.derby.impl.store.raw.data.StreamFileContainer.fetchNext(Unknown Source)
> at org.apache.derby.impl.store.raw.data.StreamFileContainerHandle.fetchNext(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeScan.mergeARow(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeScan.init(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeSort.openSortScan(Unknown Source)
> at org.apache.derby.impl.store.access.RAMTransaction.openSortScan(Unknown Source)
> at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.loadSorter(Unknown Source)
> at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.openCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source)
> at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source)
> at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source)
> at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
> at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
> at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
> at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
> at org.apache.derby.tools.ij.main(Unknown Source)
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readBoolean(DataInputStream.java:248)
> at org.apache.derby.impl.sql.execute.MaxMinAggregator.readExternal(Unknown Source)
> at org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(Unknown Source)
> at org.apache.derby.iapi.types.UserType.readExternal(Unknown Source)
> ... 22 more
> ============= begin nested exception, level (1) ===========
> java.io.EOFException
> at java.io.DataInputStream.readBoolean(DataInputStream.java:248)
> at org.apache.derby.impl.sql.execute.MaxMinAggregator.readExternal(Unknown Source)
> at org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(Unknown Source)
> at org.apache.derby.iapi.types.UserType.readExternal(Unknown Source)
> at org.apache.derby.impl.store.raw.data.StreamFileContainer.fetchNext(Unknown Source)
> at org.apache.derby.impl.store.raw.data.StreamFileContainerHandle.fetchNext(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeScan.mergeARow(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeScan.init(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeSort.openSortScan(Unknown Source)
> at org.apache.derby.impl.store.access.RAMTransaction.openSortScan(Unknown Source)
> at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.loadSorter(Unknown Source)
> at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.openCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source)
> at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source)
> at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source)
> at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
> at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
> at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
> at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
> at org.apache.derby.tools.ij.main(Unknown Source)
> ============= end nested exception, level (1) ===========
> Cleanup action completed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.