On 27/03/13 15:11, Simon Helsen wrote:
thanks for checking if there is a windows-specific problem here. As for
the oddity of the test suite, not sure what you mean.
Only that it is throwing up a problem when nothing else (yet?) seems to
be. The occasional-ness is odd as well if the change you made affects
it other than timing/ordering.
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
The location name issue was only a guess I'm afraid. I'm not even sure
it would cause that exception.
Andy
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
