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
From:
Andy Seaborne <[email protected]>
To:
[email protected],
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
