Re: AW: AW: AW: CoreContainer#createAndLoad, existing cores not loaded
On 1/29/2015 11:37 PM, Clemens Wyss DEV wrote: The recommendation these days is to NOT use the embedded server We would love to, as it is clear that this is not the Solr-way to go. The reason for us building upon EmbeddedSolrServer is, we have more than 150sites, each with ist own index (core). If we'd go client server then we could no easily update the solr server(s) without also updating all clients (i.e. the 150 sites) at same time. And having a dedicated Solr server for every client/site is not really an option, is it? Or can for example a 4.10.3 client talk to a Solr 5/6 Server? Also when updating the Solr server, doesn't that also require a re-index of all data as the Luncene-storage format might have changed? Cross-version compatibility between SolrJ and Solr is very high, as long as you're not running SolrCloud. SolrCloud is *incredibly* awesome, but it's not for everyone. Without SolrCloud, the communication is http only, using very stable APIs that have been around since pretty much the beginning of Solr. In the 1.x and 3.x days, there were occasional code tweaks required for cross-version compatibility, but the API has been extremely stable since early 4.x -- for a couple of years now. SolrCloud is much more recent and far more complex, so problems or deficiencies are sometimes found with the API. Fixing those bugs sometimes requires changes that are incompatible with other versions of the Java client. The SolrJ java client is an integral part of Solr itself, so SolrCloud functionality in the client is tightly coupled to specifics in the API that are undergoing rapid change from version to version. I don't think that SolrCloud is even possible with the embedded server, because it requires HTTP for inter-server communication. The embedded server doesn't listen for HTTP. Thanks, Shawn
AW: AW: AW: CoreContainer#createAndLoad, existing cores not loaded
I looked into sources of CoreAdminHandler#handleCreateAction ... SolrCore core = coreContainer.create(dcore); // only write out the descriptor if the core is successfully created coreContainer.getCoresLocator().create(coreContainer, dcore); ... I was missing the coreContainer.getCoresLocator().create(coreContainer, dcore); When doing the two calls: a) Core.properties is being created AND b) the cores are being loaded upon container-startup ;) :-) -Ursprüngliche Nachricht- Von: Clemens Wyss DEV [mailto:clemens...@mysign.ch] Gesendet: Freitag, 30. Januar 2015 07:38 An: solr-user@lucene.apache.org Betreff: AW: AW: AW: CoreContainer#createAndLoad, existing cores not loaded The recommendation these days is to NOT use the embedded server We would love to, as it is clear that this is not the Solr-way to go. The reason for us building upon EmbeddedSolrServer is, we have more than 150sites, each with ist own index (core). If we'd go client server then we could no easily update the solr server(s) without also updating all clients (i.e. the 150 sites) at same time. And having a dedicated Solr server for every client/site is not really an option, is it? Or can for example a 4.10.3 client talk to a Solr 5/6 Server? Also when updating the Solr server, doesn't that also require a re-index of all data as the Luncene-storage format might have changed? -Ursprüngliche Nachricht- Von: Shawn Heisey [mailto:apa...@elyograg.org] Gesendet: Donnerstag, 29. Januar 2015 20:30 An: solr-user@lucene.apache.org Betreff: Re: AW: AW: CoreContainer#createAndLoad, existing cores not loaded On 1/29/2015 10:15 AM, Clemens Wyss DEV wrote: to put your solr home inside the extracted WAR We are NOT using war's coreRootDirectory I don't have this property in my sorl.xml If there will only be core.properties files in that cores directory Again, I see no core.properties file. I am creating my cores through CoreContainer.createCore( CordeDescriptor). The folder(s) are created but no core.properties file I am pretty clueless when it comes to the embedded server, but if you are creating the cores in the java code every time you create the container, I bet what I'm telling you doesn't apply at all. The solr.xml file may not even be used. The recommendation these days is to NOT use the embedded server. There are too many limitations and it doesn't receive as much user testing as the webapp. Start Solr as a separate process and access it over http. The overhead of http on a LAN is minimal, and over localhost it's almost nothing. To do that, you would just need to change your code to use one of the client objects. That would probably be HttpSolrServer, which is renamed to HttpSolrClient in 5.0. They share the same parent object as EmbeddedSolrServer. Most of the relevant methods used come from the parent class, so you would need very few code changes. Thanks, Shawn
AW: AW: AW: CoreContainer#createAndLoad, existing cores not loaded
The recommendation these days is to NOT use the embedded server We would love to, as it is clear that this is not the Solr-way to go. The reason for us building upon EmbeddedSolrServer is, we have more than 150sites, each with ist own index (core). If we'd go client server then we could no easily update the solr server(s) without also updating all clients (i.e. the 150 sites) at same time. And having a dedicated Solr server for every client/site is not really an option, is it? Or can for example a 4.10.3 client talk to a Solr 5/6 Server? Also when updating the Solr server, doesn't that also require a re-index of all data as the Luncene-storage format might have changed? -Ursprüngliche Nachricht- Von: Shawn Heisey [mailto:apa...@elyograg.org] Gesendet: Donnerstag, 29. Januar 2015 20:30 An: solr-user@lucene.apache.org Betreff: Re: AW: AW: CoreContainer#createAndLoad, existing cores not loaded On 1/29/2015 10:15 AM, Clemens Wyss DEV wrote: to put your solr home inside the extracted WAR We are NOT using war's coreRootDirectory I don't have this property in my sorl.xml If there will only be core.properties files in that cores directory Again, I see no core.properties file. I am creating my cores through CoreContainer.createCore( CordeDescriptor). The folder(s) are created but no core.properties file I am pretty clueless when it comes to the embedded server, but if you are creating the cores in the java code every time you create the container, I bet what I'm telling you doesn't apply at all. The solr.xml file may not even be used. The recommendation these days is to NOT use the embedded server. There are too many limitations and it doesn't receive as much user testing as the webapp. Start Solr as a separate process and access it over http. The overhead of http on a LAN is minimal, and over localhost it's almost nothing. To do that, you would just need to change your code to use one of the client objects. That would probably be HttpSolrServer, which is renamed to HttpSolrClient in 5.0. They share the same parent object as EmbeddedSolrServer. Most of the relevant methods used come from the parent class, so you would need very few code changes. Thanks, Shawn
