Hi, I made another try moving the dbpedia index when Tomcat was stopped, in scenario 1. Looks like in this case everything works ok: 1) The default dbpedia index is kept stored in dbpedia-2013.01.16 (~ 100MB) 2) The custom dbpedia index is installed in dbpedia-2013.01.16-1
Hope this can help to understand what is happening. Cheers Andrea 2013/1/16 Andrea Di Menna <ninn...@gmail.com> > Hi Rupert, > > did some more tests also on a local machine (with Tomcat6) and I get the > following behavior: > > Scenario 1: *FAILING* > - Tomcat is installed on disk A dir /var/lib/tomcat6 > - Create a (emtpy) stanbol working dir in disk B > - Create a symbolic link from /var/lib/tomcat6/stanbol to stanbol working > dir in disk B > > Scenario 2: *SUCCESSFUL* > - Tomcat is installed on disk A dir /var/lib/tomcat6 > - No directory created, let Stanbol create a working dir itself > > The sling.fileinstall.dir parameter is set to stanbol/datafiles in the > web.xml of the webapp. > > In one try with Scenario 1, Stanbol started to create 3 different dbpedia > index dirs and it only stopped because disk space was over ;) > Is the symbolic link somehow the cause of this? > > I really don't know what is happening, but I have some more questions: > > 1) Should I explicitely set the sling.fileinstall.dir in the web.xml or I > cam omit it? (I tried using the full-war, which does not have this param > set and as far as I could see the installation was not triggered at all > copying the index into the datafiles folder - so I guess I have to set this > param to enable the datafileprovider) > > 2) Should I stop the web server before copying the index file into the > datafiles dir? Of course copying some GBs takes some time, so I am > wondering if the installation process starts as soon as the file is created > in the dir and if it is possible that the process gets confused everytime > the file changes on the disk (I know I am talking nonsense here...) > > Answers to your questions are inline. > > Thanks > > 2013/1/15 Rupert Westenthaler <rupert.westentha...@gmail.com> > >> Hi >> >> On Tue, Jan 15, 2013 at 6:35 PM, Andrea Di Menna <ninn...@gmail.com> >> wrote: >> > It is like the installing phase starts with two different concurrent >> > threads and ends up with two different indexes (which are actually the >> > same). >> > >> > What do you think the cause could be? >> >> Yes it looks like that. I never observed this, but I can think of the >> following causes >> >> (1) Maybe you have two configuration for the "Apache Stanbol Solr: >> Managed Solr Server" that both use "default" as value for the >> "org.apache.solr.core.CoreContainer.name" property. Two instances of >> the service would cause the installation to happen two times. You can >> check this in the Configuration tab of the Felix Webconsole >> > > Only one such configuration is present in the Configuration tab. > > >> (2) The same could happen if you have two versions of the >> commons.solr.managed Bundle installed. You can check this in the >> Bundle Tab of the Webconsole >> > > One one such version is present in the Bundle tab. > > >> (3) Could there be two Stanbol instances running using the same >> working directory? >> >> > There is only one Stanbol instance running. > > >> > >> > 2) I add the dbpedia.solrindex.zip (which is about 3.5 GB) to >> > stanbol/datafiles and at that moment two different folders are created >> > dbpedia-2013.01.15-1 >> > dbpedia-2013.01.15-2 >> >> If the above is not the reason for the issue you could check if both >> indexes are active. Check for open Files in both directories and what >> processes they are assigned to >> >> > Only one index is active and used by the Tomcat process. > > >> > >> > I have checked the logs, but can only see references to an error which >> > states "Too many close" on the SolrCore: >> >> That is caused by Stanbol during the deactivation of a SolrCore and >> can be ignored. >> >> Hope this helps in tracking down the reason for this behavior >> >> best >> Rupert >> >> -- >> | Rupert Westenthaler rupert.westentha...@gmail.com >> | Bodenlehenstraße 11 ++43-699-11108907 >> | A-5500 Bischofshofen >> > >
