On 27/01/13 11:45, Michael Brunnbauer wrote:
Hello Andy,
thank you. Can you see from the stack trace if my TDB is still consistent ?
It should be OK - it's inside a transaction and the update is lost; the
transaction is aborted.
The bad memory access is in reading the main database as part of the
update, not a write to the main DB.
Server restart is a good idea - it may be a heisenbug (pseudo-random
event - depends on access patterns upto that point).
How often is this happening? Predictably?
If the same error occurred during the commit phase of the transaction,
it would be a different story. But even then, restart will replay the
journal and the different pattern of usage may well mean it succeeds.
BTW - is this machine virtualized or running on real hardware?
Andy
Regards,
Michael Brunnbauer
On Sun, Jan 27, 2013 at 11:35:28AM +0000, Andy Seaborne wrote:
On 27/01/13 11:21, Michael Brunnbauer wrote:
hi all
the following exception occured during a SPARQL update on jena-fuseki-0.2.5
with jdk-7u11-linux-x64. The system has been doing SPARQL updates without
problem with jena-fuseki-0.2.5 since October and with jdk-7u11-linux-x64
since
Jan 15. I have updated the 32bit glibc yesterday but it should not be
involved
as this is a 64bit version of Java. I guess only Oracle can do something
here ?
Yes - sorry - nothing Fuseki can do. It is very frustrating when java
goes bad.
Memory mapped IO is returning errors.
You could go back an earlier JDK7 or use a JDK6.
But it might also be that your hardware is decaying or (unlikely but
possible) it's an OS bug that 7u11 happens to provoke.
Andy
00:43:16 INFO Fuseki :: [10654] POST
http://ts.foaf-search.net:3030/crawl/update
00:43:53 WARN SPARQL_Update$HttpActionUpdate :: Transaction still active
in endWriter - no commit or abort seen (forced abort)
00:43:53 WARN Fuseki :: [10654] RC = 500 : a fault occurred
in a recent unsafe memory access operation in compiled Java code
java.lang.InternalError: a fault occurred in a recent unsafe memory access
operation in compiled Java code
at
com.hp.hpl.jena.tdb.base.file.BlockAccessBase.check(BlockAccessBase.java:118)
at
com.hp.hpl.jena.tdb.base.file.BlockAccessMapped.read(BlockAccessMapped.java:93)
