thanks for checking if there is a windows-specific problem here. As for the oddity of the test suite, not sure what you mean. I am just using jena/tdb in an instance where we have relatively low write activity stretched over a long period of time, but lots of queries. I simulate this by initially loading TDB with lots of data before I start the actual relevant run. I have not properly tested on 0.9.x, although I did some early prototyping on 0.9.x where I did not see a problem, but that may have been a coincidence as I had not heavily tested at that point. Also, I have not seen the problem since I removed the commits from the read transactions, but then again, I haven't heavily tested since. I will keep an eye on it. When I see it again, I'll try repeating the run until I can force the issue again. That may give me a sense on how reproducible the problem actually is. This initial e-mail was more to see if there was either a known or easy understandable problem. It seems there isn't so we'll need more data first
thanks Simon From: Andy Seaborne <[email protected]> To: [email protected], Date: 03/27/2013 04:34 AM Subject: Re: org.apache.jena.atlas.lib.InternalErrorException: Unknown type: 0 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 <[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 >> >> >> >> > > > >
