Re: org.apache.jena.atlas.lib.InternalErrorException: Unknown type: 0

[Andy Seaborne]

On 26/03/13 21:42, Simon Helsen wrote:
interesting guess. I checked the code and I although possible in general,
it should not have happened in the tests where I ran into the problem.
What makes you say this? Are you saying the journal is sensitive to the
exact format of the index Location? (i.e. the nature of how the path looks
like?)

It's a guess - there's no evidence for this.

It would cause there to be two different transaction managers leading to 
synchronization chaos.  Even then, I don't know of a route to seeing 
zeros in the block.

We have had a lot of loading testing on the transaction system on what 
is the common path in the code base (transactions do usually commit!) 
that I'm looking for other factors.

(hmm - I think the lookup key is a string but on windows it needs to be 
case insensitive ... will check it uses the OS appropriate canonicalized 
form)

Perhaps I could force the issue by increasing the simultaneous write load.
This particular suite has a relatively low write load because of the
use-case it is mimicking.

which is odd in itself - why this suite?

Did it used to work under 0.9.X?

        Andy


Simon



From:
Andy Seaborne <a...@apache.org>
To:
dev@jena.apache.org,
Date:
03/26/2013 05:10 PM
Subject:
Re: org.apache.jena.atlas.lib.InternalErrorException: Unknown type: 0



On 26/03/13 20:35, Simon Helsen wrote:
I have removed the commit/abort for the reads and the problem is not
occurring so far although that is probably just coincidental. I will
keep
a close eye. Disk space is certainly not a problem and generally quite
reliable. The code is highly concurrent so that makes it hard to
reproduce.

I also see now why the exception stack is confusing. There is indeed
another exception coming from the servlet framework I'm using,
compounded
by the fact the at least partly the exception below is thrown in a bit
of
code which looks like this:

} catch (Throwable e) {
    dataset.end();
    throw new RuntimeException(e);
}

The trace you see is thrown inside dataset.end(). That is this bit:

com.hp.hpl.jena.sparql.core.DatasetImpl.end(DatasetImpl.java:157)
          at

com.ibm.team.integration.registry.index.TdbIndexStoreProvider$1.close(TdbIndexStoreProvider.java:279)

I guess it was written without expecting an issue in dataset.end()
itself,
but if the Throwable was thrown during a commit, it will become
complicated quickly.  I'll at least add an e.printStackTrace for now in
case it comes up again. I do think though that
org.apache.jena.atlas.lib.InternalErrorException is the original error
and
the others are just consequences of where this particular exception was
thrown

It's definitely InternalErrorException ... but the question is why is
that is happening.  Erratic ability to read the journal is somewhat odd.
It's all inside Transaction.commit which is synchronized.

Wild guess - are there two ways to name the same disk location for the DB?

                  Andy




From:
Andy Seaborne <a...@apache.org>
To:
dev@jena.apache.org,
Date:
03/26/2013 03:37 PM
Subject:
Re: org.apache.jena.atlas.lib.InternalErrorException: Unknown type: 0



On 26/03/13 15:39, Simon Helsen wrote:
Hi all,

I am currently using Jena 2.10.0 plus associated components and I am
sometimes running into an exception. Unfortunately, I don't have a
reproducible test yet as it seems (as usual) not to happen
consistently.
But looking at the code, I am not sure what I am seeing. The problem is
in
the journal, where the JournalEntryType seems to be 0 (valid values
seem
to be 1 - 6).

I tend to avoid zeros because uninitialized is often zero.

Anyone has any idea how this could happen? Perhaps I am
doing something wrong here. I noticed in my code I am executing a
commit
during a read-only transaction. I will remove this, but I thought this
was
legal. Anything I am missing?

commit() for read is fine  Or abort().


thanks

Simon


There was a panic message printed to the TDB log - was it an
IOException?

com.ibm.juno.server.RestException:
com.hp.hpl.jena.tdb.transaction.TDBTransactionException: Exc eption
after
commit point - transaction did commit
           at
com.ibm.juno.server.RestServlet.service(RestServlet.java:687)

... not good ...

Caused by: com.hp.hpl.jena.tdb.transaction.TDBTransactionException: Exc
eption after commit point - transaction did commit
           at

com.hp.hpl.jena.tdb.transaction.Transaction.commit(Transaction.java:162)
           at
com.hp.hpl.jena.tdb.transaction.Transaction.close(Transaction.java:251)
           at


com.hp.hpl.jena.tdb.transaction.DatasetGraphTxn.end(DatasetGraphTxn.java:59)
           at

...

           at
com.ibm.juno.server.RestSerializer.handle(RestSerializer.java:46)
           at
com.ibm.juno.server.RestServlet.serialize(RestServlet.java:836)
           at
com.ibm.juno.server.RestServlet.service(RestServlet.java:679)
           ... 12 more

The stacktrace above is later than this one below? or is it one
stacktrace?

Caused by: org.apache.jena.atlas.lib.InternalErrorException: Unknown
type:
0
           at


com.hp.hpl.jena.tdb.transaction.JournalEntryType.type(JournalEntryType.java:43)
           at
com.hp.hpl.jena.tdb.transaction.Journal._read(Journal.java:228)
...>          at


com.hp.hpl.jena.tdb.transaction.Transaction.commit(Transaction.java:155)
           ... 25 more

Unclear -- maybe problems reading the journal file.  Disk OK? not full?

(I'll reorg the code to read all bytes and check the checksum but that
is not the problem, it just shuffles checking around.).

                   Andy