db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [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
Date Wed, 16 Mar 2011 02:34:29 GMT

    [ 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

Mime
View raw message