Hi Gregor, I was seeing your mail but only after I sent my response as I was working offline in the train an my way from home to work.
In the trunk it is expected that two integration tests do fail. This is because the SPARQL serializer/deserializer are not yet ported to the new framework used in the trunk. If you are not planing to use the SPARQL endpoint of Stanbol this should not affect you. best Rupert On Wed, Nov 20, 2013 at 12:33 PM, Gregor Müllegger <gre...@muellegger.de> wrote: > Hi and thanks again for beeing so persistent in helping me. > > I think the TDB issue went away after I relocated the stanbol checkout to a > local directory. The tdb directory now contains all the files that you have > listed. The successfull test results of your special testcase can be found > here: http://pastebin.com/FAJKJpGT > > However I've already written a new response that might have slipped through > your inbox. It can be viewed here in total: > http://mail-archives.apache.org/mod_mbox/stanbol-dev/201311.mbox/< > caljsgcpkviffr7pl_460nrsbjjt-cpduaadf4p1fewsxqoo...@mail.gmail.com> > > The integration tests are failing with the message: > > Failed tests: > testSparqlConfig(org.apache.stanbol.enhancer.it.EnhancerConfigurationTest): > GET request to > http://localhost:8765/enhancer/sparql?query=PREFIX+enhancer%3A+%3Chttp%3A%2F%2Fstanbol.apache.org%2Fontology%2Fenhancer%2Fenhancer%23%3EPREFIX+rdfs%3A+++++%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3ESELECT+distinct+%3Fname+%3Fchain+WHERE+%7B%3Fchain+a+enhancer%3AEnhancementChain+.%3Fchain+rdfs%3Alabel+%3Fname+.%7DORDER+BY+ASC%28%3Fname%29: > expecting status 200 (content: <html>(..) > > testEngineConfig(org.apache.stanbol.enhancer.it.EnhancerConfigurationTest): > GET request to http://localhost:8765/enhancer/engine: no match for regexp > '<j.0:hasEngine > rdf:resource="http://localhost:.*/enhancer/engine/dbpediaLinking"/>', > content=(..) > > > Best regards, > Gregor > > > 2013/11/15 Rupert Westenthaler <rupert.westentha...@gmail.com> > >> Hi Gregor, >> >> The folder is expected to include the following files >> >> GOSP.dat GPOS.idn OSP.dat OSPG.idn POSG.dat SPO.idn node2id.dat >> prefix2id.dat prefixIdx.idn >> GOSP.idn GSPO.dat OSP.idn POS.dat POSG.idn SPOG.dat node2id.idn >> prefix2id.idn prefixes.dat >> GPOS.dat GSPO.idn OSPG.dat POS.idn SPO.dat SPOG.idn nodes.dat >> prefixIdx.dat stats.opt >> >> As you are missing those files it indicates that the initialization of >> the TDB store is failing. >> >> IMO this looks like an issue with Jena TDB specific to your >> environment. To validate this I have creates a minimal test module [1] >> that (1) create a Jena TDB store, (2) adds an quad and (3) a Triple to >> the default Graph. If this also fails in your Environment the logs >> should be useful to file a Bug with Jena TDB. >> >> To execute the test just extract the archive and call "mvn test" in >> the module directory. >> >> best >> Rupert >> >> [1] http://dev.iks-project.eu/downloads/stanbol-launchers/tdbtest.tar.bz2 >> >> >> >> On Thu, Nov 14, 2013 at 1:48 PM, Gregor Müllegger <gre...@muellegger.de> >> wrote: >> > Thanks Rupert for your response. >> > >> > I don't see any issues with the permissions. Everything is accessable by >> my >> > local user. I also have rerun the build with: >> > >> > sudo MAVEN_OPTS="-Xmx2048M -XX:MaxPermSize=512M" mvn clean install -e >> > >> > But that didn't work either. >> > >> > I also tried to increase the memory for the test runs by following this >> > stackoverflow answer: http://stackoverflow.com/a/12415230/199848 >> > Therefore I added the following snippet to the file >> > /vagrant/stanbol/entityhub/indexing/source/jenatdb/pom.xml >> > >> > <plugin> >> > <groupId>org.apache.maven.plugins</groupId> >> > <artifactId>maven-surefire-plugin</artifactId> >> > <configuration> >> > <forkMode>pertest</forkMode> >> > <argLine>-Xms512m -Xmx1024m</argLine> >> > <testFailureIgnore>false</testFailureIgnore> >> > <skip>false</skip> >> > <includes> >> > <include>**/*.java</include> >> > </includes> >> > </configuration> >> > </plugin> >> > >> > I have now setup a completely new virtualmachine so none of my earlier >> tries >> > interferes. But I have the same problem. >> > >> > Here is the information that will hopefully help in finding the related >> > issue: >> > >> > vagrant@precise64 >> :/vagrant/stanbol/entityhub/indexing/source/jenatdb/target/test-files/testConfigs/iterable/indexing/resources/tdb# >> > ls -lah >> > total 8.1M >> > drwxrwxr-x 1 vagrant vagrant 4.0K Nov 14 12:23 . >> > drwxrwxr-x 1 vagrant vagrant 4.0K Nov 14 12:23 .. >> > -rw-r--r-- 1 vagrant vagrant 8.0M Nov 14 12:23 node2id.dat >> > -rw-r--r-- 1 vagrant vagrant 0 Nov 14 12:23 node2id.idn >> > >> > You can find the listed files here to download: >> > >> > https://www.dropbox.com/sh/jfb5csufonxv2g8/-y49f7gN-x >> > >> > >> > Thanks so much! >> > Gregor >> > >> > 2013/11/14 Rupert Westenthaler <rupert.westentha...@gmail.com> >> > >> >> Hi Gregor, >> >> >> >> The test encounters an IOException when allocating a segment in a >> >> memory mapped file (see [1] line 221) used by Jena TDB. Based on the >> >> stack trace this happen already during the initialization of the Jena >> >> TDB store. So I my guess would be that either one of the memory mapped >> >> file used by Jena is corrupted or missing read/write permission on the >> >> file. >> >> >> >> The first can only be the case if there would still be data from a >> >> previous run of the test. Actually this test does has a known issue >> >> that it does not delete files from previous runs. Including the >> >> "clean" prevents this as this ensures that the /target folder is >> >> deleted before running the tests. >> >> >> >> To check permissions: the Jena TDB store created by the tests are >> located >> >> under >> >> >> >> >> >> >> {module-home}/target/test-files/testConfigs/{test-config-name}/indexing/resources/tdb >> >> >> >> e.g. >> >> >> >> >> >> >> /vagrant/stanbol/entityhub/indexing/source/jenatdb/target/test-files/testConfigs/iterable/indexing/resources/tdb >> >> >> >> for the failed testEntityDataIterable test. >> >> >> >> If both does not solve the issue I would suggest to provide the Jena >> >> TDB store (all files in the tdb folder) to make some further tests. >> >> >> >> best >> >> Rupert >> >> >> >> >> >> >> >> [1] >> >> >> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.jena/jena-tdb/0.10.0/com/hp/hpl/jena/tdb/base/file/BlockAccessMapped.java >> >> >> >> >> >> -- >> | Rupert Westenthaler rupert.westentha...@gmail.com >> | Bodenlehenstraße 11 ++43-699-11108907 >> | A-5500 Bischofshofen >> -- | Rupert Westenthaler rupert.westentha...@gmail.com | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
