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 <[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
