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 >
