db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3844) ASSERT failure in BasePage.unlatch() when running LobStreamsTest
Date Thu, 19 Nov 2009 11:05:40 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779935#action_12779935
] 

Kristian Waagan commented on DERBY-3844:
----------------------------------------

Your understanding is correct, Bryan.

Something along the lines you describe will most probably work, but may require changes to
the stream class down in store. You have one real source stream, but other streams may be
"spliced off" from it. Add another couple of layers and you're up into the outer JDBC realm
:)

Unfortunately, I think we have issues we cannot address at this level. I don't have a deep
enough understanding of what's going on yet, but I hope to spend some more time investigating
soon.
One thing we have to do, is to agree on what is going to be allowed. From the realm of Blobs,
consider these pieces of pseudo-code:

1) select blob as b1, blob as b2 from blobtable

2) // Pattern where the Blob references aren't kept. GC has side-effects currently.
    stream = rs.getBlob(1).getBinaryStream()
    length = rs.getBlob(1).length()
    // Do something here, assume GC / finalization will take place.
    // Now read from the stream.
    stream.read(buf) // <-- fails

3) Blob b1 = rs.getBlob(1)
    // Process b1.
    // Note sure if b2 will be invalid if b1.free() is called here, or if obtaining b2 will
latch/lock the resources again.
    // If you obtain b1 and b2 at the same time, and then call free on one of them, the other
will be invalidated.
    Blob b2 = rs.getBlob(1)
    // Process b2.

4) Blob b1 = rs.getBlob(1)
    stream1 = b1.getBinaryStream(1024, 4096)
    stream2 = b1.getBinaryStream(10240, 2048)
    // Process both streams "concurrently"

- (1) is definitely allowed by SQL. This is the simple example, a cross join is more complex
and may end up referencing the same Blob multiple times (in different rows of the result).
- In (2), should it be forbidden to call getBlob(1) multiple times, should we return the same
Blob object, or should the two Blobs be independent on each other? This gets worse if updates
come into play...
- Case (3) is much like (2), but the effects on the two Blob objects are caused by explicit
method calls only.
- (4) adds yet another level, and here we support update-aware streams currently. In this
case I believe we're talking about changes to this specific Blob-instance.

I think (1) and (4) may be the more natural use-cases, whereas (2) and (3) can be categorized
as corner cases (?). All issues here are related to having several handles to the same source
data.
With the exception of class (1), the user can work around these issues by changing the application
code (unless a framework generates / uses code that trigger these issues). The whole thing
would just be simpler to deal with if there were clear rules :)


Related Jiras: DERBY-3645, DERBY-3646 and DERBY-3650 (there are probably more)

> ASSERT failure in BasePage.unlatch() when running LobStreamsTest
> ----------------------------------------------------------------
>
>                 Key: DERBY-3844
>                 URL: https://issues.apache.org/jira/browse/DERBY-3844
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.5.1.1
>         Environment: Solaris 10, AMD Opteron with 2 CPUs, Java(TM) SE Runtime Environment
(build 1.6.0_06-b02), Derby trunk revision 686755
>            Reporter: Knut Anders Hatlen
>         Attachments: derby-3844-1a-repro_test.diff
>
>
> I saw this failure when running suites.All to test the patch nested_transaction_v2.diff
which is posted on DERBY-3693. The failure did not occur when I reran the test, and I don't
believe the patch should have any effect on the code that failed. The ASSERT that is triggered
is this one (which indicates that we're trying to unlatch a page that's not latched):
> 		if (SanityManager.DEBUG) {
> 			SanityManager.ASSERT(isLatched());
> 		}
> Here's the full stack trace and thread dump:
> 1) testBlobWrite3Param(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest)org.apache.derby.shared.common.sanity.AssertFailure:
ASSERT FAILED
> 	at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:98)
> 	at org.apache.derby.impl.store.raw.data.BasePage.unlatch(BasePage.java:1319)
> 	at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:152)
> 	at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:44)
> 	at java.io.DataInputStream.read(DataInputStream.java:132)
> 	at org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:106)
> 	at org.apache.derby.impl.jdbc.AutoPositioningStream.read(AutoPositioningStream.java:113)
> 	at org.apache.derby.impl.jdbc.UpdatableBlobStream.read(UpdatableBlobStream.java:194)
> 	at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.readBytesFromStream(LobStreamsTest.java:463)
> 	at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.compareLob2File(LobStreamsTest.java:488)
> 	at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testBlobWrite3Param(LobStreamsTest.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> ---------------
> Stack traces for all live threads:
> Thread name=derby.antiGC id=280 priority=1 state=WAITING isdaemon=true
> 	java.lang.Object.wait(Native Method)
> 	java.lang.Object.wait(Object.java:485)
> 	org.apache.derby.impl.services.monitor.AntiGC.run(BaseMonitor.java:2217)
> 	java.lang.Thread.run(Thread.java:619)
> Thread name=Signal Dispatcher id=4 priority=9 state=RUNNABLE isdaemon=true
> Thread name=main id=1 priority=5 state=RUNNABLE isdaemon=false
> 	java.lang.Thread.dumpThreads(Native Method)
> 	java.lang.Thread.getAllStackTraces(Thread.java:1477)
> 	org.apache.derby.shared.common.sanity.ThreadDump.getStackDumpString(ThreadDump.java:34)
> 	sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	org.apache.derby.shared.common.sanity.AssertFailure$1.run(AssertFailure.java:165)
> 	java.security.AccessController.doPrivileged(Native Method)
> 	org.apache.derby.shared.common.sanity.AssertFailure.dumpThreads(AssertFailure.java:159)
> 	org.apache.derby.shared.common.sanity.AssertFailure.<init>(AssertFailure.java:82)
> 	org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:98)
> 	org.apache.derby.impl.store.raw.data.BasePage.unlatch(BasePage.java:1319)
> 	org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:152)
> 	org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:44)
> 	java.io.DataInputStream.read(DataInputStream.java:132)
> 	org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:106)
> 	org.apache.derby.impl.jdbc.AutoPositioningStream.read(AutoPositioningStream.java:113)
> 	org.apache.derby.impl.jdbc.UpdatableBlobStream.read(UpdatableBlobStream.java:194)
> 	org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.readBytesFromStream(LobStreamsTest.java:463)
> 	org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.compareLob2File(LobStreamsTest.java:488)
> 	org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testBlobWrite3Param(LobStreamsTest.java:130)
> 	sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104)
> 	junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	junit.extensions.TestSetup.run(TestSetup.java:25)
> 	org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> Thread name=derby.rawStoreDaemon id=941 priority=5 state=TIMED_WAITING isdaemon=true
> 	java.lang.Object.wait(Native Method)
> 	org.apache.derby.impl.services.daemon.BasicDaemon.rest(BasicDaemon.java:571)
> 	org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:388)
> 	java.lang.Thread.run(Thread.java:619)
> Thread name=Timer-3 id=281 priority=5 state=WAITING isdaemon=true
> 	java.lang.Object.wait(Native Method)
> 	java.lang.Object.wait(Object.java:485)
> 	java.util.TimerThread.mainLoop(Timer.java:483)
> 	java.util.TimerThread.run(Timer.java:462)
> Thread name=Finalizer id=3 priority=8 state=WAITING isdaemon=true
> 	java.lang.Object.wait(Native Method)
> 	java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
> 	java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
> 	java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
> Thread name=Reference Handler id=2 priority=10 state=WAITING isdaemon=true
> 	java.lang.Object.wait(Native Method)
> 	java.lang.Object.wait(Object.java:485)
> 	java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
> Thread name=derby.rawStoreDaemon id=933 priority=5 state=TIMED_WAITING isdaemon=true
> 	java.lang.Object.wait(Native Method)
> 	org.apache.derby.impl.services.daemon.BasicDaemon.rest(BasicDaemon.java:571)
> 	org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:388)
> 	java.lang.Thread.run(Thread.java:619)
> ---------------

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message