Hello Andy, the problem was a bad block on the disk (I should have checked this first). It was not automatically corrected as TDB tried to read from it and failed (drives only relocate bad blocks on write). I will throw away the TDB on this disk as it is most probably inconsistent and use the backup.
Regards, Michael Brunnbauer On Sun, Jan 27, 2013 at 12:18:09PM +0000, Andy Seaborne wrote: > 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) > > -- ++ Michael Brunnbauer ++ netEstate GmbH ++ Geisenhausener Straße 11a ++ 81379 München ++ Tel +49 89 32 19 77 80 ++ Fax +49 89 32 19 77 89 ++ E-Mail bru...@netestate.de ++ http://www.netestate.de/ ++ ++ Sitz: München, HRB Nr.142452 (Handelsregister B München) ++ USt-IdNr. DE221033342 ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
