[jira] [Resolved] (DERBY-5624) System can run out of stack space while processing DropOnCommit requests.

["Mike Matrigali (Resolved) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-5624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Matrigali resolved DERBY-5624.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 10.8.2.3
                   10.7.1.4
                   10.6.2.3
                   10.5.3.2

fixed in trunk and backported to 10.8, 10.7, 10.6, and 10.5.  

	DERBY-5624 System can run out of stack space while processing DropOnCommit requests.

Taking care of cleanup after a commit is handled by notifying all "Observers"
that an event has taken place that they might want to act on and cleanup. In
the added test case this is triggered by off line commit which effectively
drops and recreates the base table and all of its indexes after loading the
data into them.

Sometimes these Observers may execute work which adds to the Observer queue,
and that queue can "miss" them in the first pass through.

A previous fix for this problem added a recursive call to notifyObservers in
the place that could cause this addition of observers. This recursive call
was causing stack problems when the number of Observers became large. For
the checked in test case this was 1000 indexes on 1000 columns of the table.
For other users I believe the cause was a by product of sorts on large disk
based sorts for multi-gigabyte tables and indexes. 2 users were reporting
similar failed stacks for failing compresses of large tables, and one was
able to take this fix to their environment and then successfully run the
compress.

The fix was to remove the recursion and instead loop at the outermost point
until there were no Observers.

Adding the test to the largedata suite as it takes over 10 minutes to run
on my machine. 
                
> System can run out of stack space while processing DropOnCommit requests.
> -------------------------------------------------------------------------
>
>                 Key: DERBY-5624
>                 URL: https://issues.apache.org/jira/browse/DERBY-5624
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.5.3.2, 10.8.2.2
>            Reporter: Mike Matrigali
>            Assignee: Mike Matrigali
>              Labels: derby_triage10_9
>             Fix For: 10.5.3.2, 10.6.2.3, 10.7.1.4, 10.8.2.3, 10.9.0.0
>
>         Attachments: DERBY-5624.patch, error-stacktrace_mod.out, largedatasuite_mod.out
>
>
> The system currently recursively calls xact.notifyObservers() from DropOnCommit.update().  It does this because in some cases
> new observers can be added while processing the list of notifyObservers and those were being missed before the change, causing
> Assertions in the tests and possibly files not properly dropped on commit.
> Multiple users on the Derby user list have had failures running SYSCS_UTIL.SYSCS_COMPRESS_TABLE(), running out of stack track
> with a heavily recursive stack trace of the form (see more detail from these reports in subsequent comments):
> Caused by: java.lang.StackOverflowError
> at java.lang.ThreadLocal.get(ThreadLocal.java:125)
> at java.lang.StringCoding.deref(StringCoding.java:46)
> at java.lang.StringCoding.encode(StringCoding.java:258)
> at java.lang.String.getBytes(String.java:946)
> at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
> at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)
> at java.io.File.exists(File.java:733)
> at org.apache.derby.impl.store.raw.data.StreamFileContainer.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.apache.derby.impl.store.raw.data.StreamFileContainer.privExists(Unknown Source)
> at org.apache.derby.impl.store.raw.data.StreamFileContainer.open(Unknown Source)
> at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openStreamContainer(Unknown Source)
> at org.apache.derby.impl.store.raw.xact.Xact.openStreamContainer(Unknown Source)
> at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.dropStreamContainer(Unknown Source)
> at org.apache.derby.impl.store.raw.xact.Xact.dropStreamContainer(Unknown Source)
> at org.apache.derby.impl.store.raw.data.DropOnCommit.update(Unknown Source)
> at java.util.Observable.notifyObservers(Observable.java:142)
> at org.apache.derby.iapi.store.raw.xact.RawTransaction.notifyObservers(Unknown Source)
> at org.apache.derby.impl.store.raw.data.DropOnCommit.update(Unknown Source)
> at java.util.Observable.notifyObservers(Observable.java:142)
> at org.apache.derby.iapi.store.raw.xact.RawTransaction.notifyObservers(Unknown Source)
> at org.apache.derby.impl.store.raw.data.DropOnCommit.update(Unknown Source)
> at java.util.Observable.notifyObservers(Observable.java:142)
> at org.apache.derby.iapi.store.raw.xact.RawTransaction.notifyObservers(Unknown Source)
> at org.apache.derby.impl.store.raw.data.DropOnCommit.update(Unknown Source)
> at java.util.Observable.notifyObservers(Observable.java:142)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira