You most definitely do NOT want to bring up a new SolrCore for every query - there are lots of caches and warming that you want to take advantage of. I think the actual EmbeddedSolrServer is safe to instantiate fresh as it's lightweight, but you do want to keep some things persistent across requests.

        Erik

On Jul 15, 2009, at 1:16 PM, Ravish007 wrote:


Hi Erik & Ryan,
The Java code snippet of yours was very helpful. I just wanted to ask you
one question about keeping JVM running.  Is it a good idea to keep it
running for the duration the application that has it embedded runs and
terminate it with the application only? Won't it be very wasteful if you
open and close the server for every query?  (Very sorry if I am asking
stupid question but I am new to this libraries). Thanks for your post. :)

Also on Solr Wiki page here:
http://wiki.apache.org/solr/Solrj#head-02003c15f194db1a691f8b9bb909145a60ccf498

they don't create a "core" object.  Instead they just do:
CoreContainer.Initializer initializer = new CoreContainer.Initializer();
CoreContainer coreContainer = initializer.initialize();

If I do the same, is it fine if I just do coreContainer.shutdown();? It
should have the same effect right?

Thanks.
Ravi






Erik Hatcher wrote:

Thanks Ryan - good tips, and core.close() was the missing piece, duh.

Here's how it looks in JRuby:

  container = CoreContainer.new
  descriptor = CoreDescriptor.new(container, "core1", "/Users/erik/
apache-solr-1.3.0/example/solr")
  core = container.create(descriptor)
  container.register("core1", core, false)

  solr = EmbeddedSolrServer.new(container, "core1")
  query = SolrQuery.new("*:*")
  response = solr.query(query)
  puts response
  core.close

Perhaps there should be an overloaded CoreContainer#register(core)
that uses the name from the core descriptor so "core1" doesn't have to
be duplicated?

        Erik


On Oct 2, 2008, at 10:37 AM, Ryan McKinley wrote:

You could also use the CoreContainer to create a Core from the
descriptor:

  CoreContainer container = new CoreContainer();
  CoreDescriptor descriptor = new CoreDescriptor(container,
      "core1", "/Users/erik/apache-solr-1.3.0/example/solr");
  SolrCore core = container.create( descriptor );

if you are using a custom solrconfig name, you would need to call
setConfigName( path ) on the descriptor.

As for closing...  have you tried core.close()?

ryan


On Oct 2, 2008, at 8:49 AM, Erik Hatcher wrote:

I'm doing some Java experiments to get ready for a solr-ruby
overhaul such that JRuby comes into play nicely so that
EmbeddedSolrServer can be used transparently too.  I've not tried
this since the whole CoreContainer/CoreDescriptor stuff was added,
and I don't quite understand it all.  Here's what I've got:

public static void main(String[] args) throws IOException,
ParserConfigurationException, SAXException, SolrServerException {
 CoreContainer container = new CoreContainer();
 SolrConfig config = new SolrConfig("/Users/erik/apache-solr-1.3.0/
example/solr", "solrconfig.xml", null);
 CoreDescriptor descriptor = new CoreDescriptor(container,
"core1", "/Users/erik/apache-solr-1.3.0/example/solr");
 SolrCore core = new SolrCore("core1", "/Users/erik/apache-
solr-1.3.0/example/solr/data", config, null, descriptor);
 container.register("core1", core, false);
 SolrServer solr = new EmbeddedSolrServer(container, "core1");
 SolrQuery query = new SolrQuery("*:*");
 QueryResponse response = solr.query(query);
 System.out.println("response = " + response);
}

This works, but has a fair bit of seemingly unnecessary
duplication, and it also leaves the JVM stays running for some
reason.

Is this the proper way to use EmbeddedSolrServer, or are there some
tips to improving the code and reducing the duplication?

Also, why does the JVM keep running?  Are we spinning off a thread
that needs to be shut down?  Is there some sort of close() call
that is needed?

Thanks,
        Erik





--
View this message in context: 
http://www.nabble.com/EmbeddedSolrServer-API-usage-tp19778623p24502310.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Reply via email to