[
https://issues.apache.org/jira/browse/DERBY-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231023#comment-13231023
]
Kristian Waagan commented on DERBY-5661:
----------------------------------------
I can reproduce the errors on my system.
Both sane and insane builds fail.
I don't know what it really tells us, but when I comment out
clearSequenceCaches() in the DD the test runs without these errors.
Could this be caused by the contention problems seen for identity columns?
The code in the istat daemon isn't ready to deal with lcc.internalRollback()
failing due to a lock timeout on SYSEQUENCES. After this happens the DD state
appears to be invalid (I have not checked if it is possible to recover). This
results in ASSERTs in sane builds and various runtime exceptions in the insane
build (for instance AIOOBE and NPE).
> ASSERT failure in nstest; Exception in thread "derby.index-stat-thread"
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED
> transaction not pristine
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5661
> URL: https://issues.apache.org/jira/browse/DERBY-5661
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.9.0.0
> Environment: windows XP with ibm 1.6 sr9
> Reporter: Myrna van Lunteren
> Attachments: derby.log_run4_nobackup, derby.log_run5_wbackup,
> nstest.out_run4_nobackup, nstest.out_run5_wbackup
>
>
> While running the small configuration of nstest with trunk/sane jars on a
> windows machine, I saw this a few times (in addition to the Assert failure as
> described in DERBY-5428):
> Exception in thread "derby.index-stat-thread"
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED
> transaction not pristine
> at
> org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162)
> at
> org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
> at
> org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.processingLoop(IndexStatisticsDaemonImpl.java:849)
> at
> org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.run(IndexStatisticsDaemonImpl.java:714)
> at java.lang.Thread.run(Thread.java:736)
> There is a print out of all threads following. I'll attach a couple of result
> files obtained this way.
> One run was with the backup thread running, the other without (by adding
> -Dderby.nstest.backupRestore=false)
--
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
