Hi Daniel,
Assert failures are not good for sure. My guess is, in some case
the release of a cached item is getting called more than once. In a
rare scenario it is possible that this can cause the item to be
cleaned from cache even if some one else is using it.
I don't know how serious this error is without finding what is causing
it. You may want to file a Jira entry with the information you have.
Typically Assert failures write full stack traces to derby.log ,
please add the error log file to the Jira entry. If you can get
reproducible test case that will be great, but I think that is going
to be hard.
Thanks
-suresh
Daniel Noll wrote:
I had some long-running process going over the past few days which was
extremely database intensive (insert intensive, as opposed to query
intensive.)
I got in this morning to find a weird error message which Google
apparently hasn't seen before:
Caused by: SQL Exception: Java exception: 'ASSERT FAILED item is not
kept in release(Cachable):
org.apache.derby.iapi.services.sanity.AssertFailure'.
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:80)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:92)
at org.apache.derby.impl.jdbc.Util.javaException(Util.java:210)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:387)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1296)
at
org.apache.derby.impl.jdbc.EmbedConnection.commit(EmbedConnection.java:866)
Is this serious? I did about 12 6-hour runs in a row, and it was the
11th which died. All runs were identical so I suppose this must be an
intermittent problem at best.
Daniel
