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 "Mike Matrigali (JIRA)" <ji...@apache.org> on 2011/03/16 03:34:29 UTC
[jira] Commented: (DERBY-3993) With IBM 1.6 T_RawStoreFactory fails
with There should be 0 observers, but we still have 1 observers on Win 2K
[ https://issues.apache.org/jira/browse/DERBY-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007322#comment-13007322 ]
Mike Matrigali commented on DERBY-3993:
---------------------------------------
This is reproducing every time in my current environment: sane classes, windows,
java version:
s1_ibm16:56>java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pwi3260sr9-20101125_01(SR9))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260sr9-20101124_69295 (JIT enabled, AOT enabled)
J9VM - 20101124_069295
JIT - r9_20101028_17488ifx2
GC - 20101027_AA)
JCL - 20101119_01
The problem will only show up in SANE builds as that is the only time we do the sanity check.
Xact.doComplete() is called near the end of the transaction to take care of any cleanup prior to committing or aborting the transaction.
It calls notifyObservers(commitOrAbort) and it expects on return that each observer has been notified, and all the observers are coded
to delete themselves from the observer list as part of this process. It then asserts that the list should be empty on return.
The problem that I am seeing is that one of the observers as part of it's processing manages to add another observer to the list. I am
guessing that the problem becomes intermittent because either different JVM's/memory layouts/hash algorithms result in the order processing of the
observer list to be different, or different implementations handle the adding of an observer to the list while scanning the list differently.
In my case in order to process a drop of a container marked drop on commit the raw store interface requires it to first be opened. The code adds
a TruncateOnCommit as part of this open as that layer of the code does not know why it is being opened. I believe it is this "new" TruncateOnCommit
observer which is left on the observer queue. Adding an extra notify to the drop on commit processing seems to fix the unit test, I'll see if that causes
any problems in the full set of tests.
> With IBM 1.6 T_RawStoreFactory fails with There should be 0 observers, but we still have 1 observers on Win 2K
> --------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3993
> URL: https://issues.apache.org/jira/browse/DERBY-3993
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.5.1.1
> Environment: java version "1.6.0"
> Java(TM) SE Runtime Environment (build pwi3260sr3-20081106_07(SR3))
> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20081105_25433 (JIT enabled, AOT enabled)
> J9VM - 20081105_025433_lHdSMr
> JIT - r9_20081031_1330
> GC - 20081027_AB)
> JCL - 20081106_01
> Reporter: Kathey Marsden
> Assignee: Mike Matrigali
> Priority: Minor
> Labels: derby_triage10_8
> Attachments: assert.diff
>
>
> On Win2K T_RawStoreFactory fails consistently with
> java version "1.6.0"
> Java(TM) SE Runtime Environment (build pwi3260sr3-20081106_07(SR3))
> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20081105_25433 (JIT enabled, AOT enabled)
> J9VM - 20081105_025433_lHdSMr
> JIT - r9_20081031_1330
> GC - 20081027_AB)
> JCL - 20081106_01
> *** Start: T_RawStoreFactory jdk1.6.0 2008-12-17 09:37:49 ***
> 2 del
> < -- Unit Test T_RawStoreFactory finished
> 2 add
> > There should be 0 observers, but we still have 1 observers.
> > Shutting down due to unit test failure.
> Test Failed.
> I have seen the same failure on Linux and Windows XP intermittently with IBM 1.6.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira