Strange assert failure, should I be worried?

[Daniel Noll <da...@nuix.com.au>]

Hi all.

Our application was reading from a BLOB stream, and allegedly something 
went wrong during the transaction (which is why we're seeing rollback 
here.)  We retry in such an event but apparently three failures in a row 
must have occurred, in which case we give up.  What baffles me the most 
is that I can't see any error with what's actually being displayed 
on-screen -- the data is all correct.

> org.apache.derby.iapi.services.sanity.AssertFailure: ASSERT FAILED setCurrentContextManager - mismatch threads - current Thread[(thread class)$1,6,main] - cm's Thread[(thread class)$1,6,main]
>     at org.apache.derby.iapi.services.sanity.SanityManager.THROWASSERT(SanityManager.java:150)
>     at org.apache.derby.iapi.services.context.ContextService.setCurrentContextManager(ContextService.java:333)
>     at org.apache.derby.impl.jdbc.TransactionResourceImpl.setupContextStack(TransactionResourceImpl.java:274)
>     at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(EmbedConnection.java:1464)
>     at org.apache.derby.impl.jdbc.EmbedConnection.rollback(EmbedConnection.java:894)
>     at com.nuix.store.database.DatabaseWrapper.wrap(DatabaseWrapper.java:91)
>     at com.nuix.store.binary.DatabaseBinaryStore$StoredInputStream.read(DatabaseBinaryStore.java:413)

So should I be worried about this kind of error?  It's the first time 
I've ever seen one, and viewing the same data over and over doesn't seem 
to reproduce the problem.

Daniel

-- 
Daniel Noll

Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia    Ph: +61 2 9280 0699
Web: http://www.nuix.com.au/                        Fax: +61 2 9212 6902

This message is intended only for the named recipient. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
message or attachment is strictly prohibited.

Re: Strange assert failure, should I be worried?

[Dy...@Sun.COM]

Daniel Noll <da...@nuix.com.au> writes:

> Hi all.
>
> Our application was reading from a BLOB stream, and allegedly
> something went wrong during the transaction (which is why we're seeing
> rollback here.)  We retry in such an event but apparently three
> failures in a row must have occurred, in which case we give up.  What
> baffles me the most is that I can't see any error with what's actually
> being displayed on-screen -- the data is all correct.
>
>> org.apache.derby.iapi.services.sanity.AssertFailure: ASSERT FAILED setCurrentContextManager - mismatch threads - current Thread[(thread class)$1,6,main] - cm's Thread[(thread class)$1,6,main]
>>     at org.apache.derby.iapi.services.sanity.SanityManager.THROWASSERT(SanityManager.java:150)
>>     at org.apache.derby.iapi.services.context.ContextService.setCurrentContextManager(ContextService.java:333)
>>     at org.apache.derby.impl.jdbc.TransactionResourceImpl.setupContextStack(TransactionResourceImpl.java:274)
>>     at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(EmbedConnection.java:1464)
>>     at org.apache.derby.impl.jdbc.EmbedConnection.rollback(EmbedConnection.java:894)
>>     at com.nuix.store.database.DatabaseWrapper.wrap(DatabaseWrapper.java:91)
>>     at com.nuix.store.binary.DatabaseBinaryStore$StoredInputStream.read(DatabaseBinaryStore.java:413)
>
> So should I be worried about this kind of error?  It's the first time
> I've ever seen one, and viewing the same data over and over doesn't
> seem to reproduce the problem.

Hmm, I don't know if you should be worried, but it worries me. I think
this must be a Derby bug of some sort, but I expect the Cloudscape
gurus in California will have more to say about it when they wake up.

The strange thing though, is that this assert is triggered at all. It claims
that 'Thread.currentThread() != cm.activeThread()'. But when it does a
toString() on those two objects, they appear to be identical:

Thread.currentThread(): Thread[(thread class)$1,6,main]
cm.activeThread():      Thread[(thread class)$1,6,main]

Can you have two different Thread objects for which toString() returns the
same String? Should the test and printout have been synchronized on
cm? Did another thread modify cm's activeThread between the ref
comparison and the toString conversion?

-- 
dt