Hello Andy, thank you. Can you see from the stack trace if my TDB is still consistent ?
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 [email protected] ++ 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
