Hi Andrea Thanks for all those information. I will try to reproduce this behavior in the coming days. I will keep you informed.
best Rupert On Wed, Jan 16, 2013 at 5:24 PM, Andrea Di Menna <ninn...@gmail.com> wrote: > 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 >>> >> >> -- | Rupert Westenthaler rupert.westentha...@gmail.com | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
