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