CloudSolrServer can be used for indexing and is smart about indexing since it knows the current cluster state.
For 4.0 I'd use one per collection because there is a bug around this fixed in the upcoming 4.1 (using one for more than one collection). In fact, if you are moving to 4, it's a good idea to get your feet wet with 4.0, but I'd hold off for 4.1 for production if you can. Huge number of bug fixes and improvements. - Mark On Jan 4, 2013, at 10:06 AM, Jay Parashar <jparas...@itscape.com> wrote: > Hi, > > I am trying to migrate to Solr 4 (from 3.6) for a > multithreaded/multicollection environment using the Solrj java client. I need > some clarification of when to use the > Cloud Solr Server vs LBHttpSolrServer. Any help is appreciated. > > Which one do I use? The CloudSolrServer uses the LB server internally so > should this be the one for both searching and indexing? The documentation > says the LB server must not be used for indexing. As the CloudSolrServer uses > the LB server internally, so I guess we should not use it for indexing. Is > this correct? > So if the ConcurrentUpdateSolrServer is used for indexing, how do I load > balance that? > > Reusing: > Should I create multiple Cloud Solr Servers, one for each collection? Simply > put, what is the best practice for reusing a server in a > multithreaded/multicollection scenario and what server do I use for indexing > and querying? The CloudSolrServer instantiates a new LB server per request. > Isn't that expensive? > > On Solr 3.6, I used the ConcurrentUpdateSolrServer for indexing and the > HttpSolrServer for searching. In each case, I had a new server per core and > reused (I used a MAP with the corename as key and the server as the value). > So for 5 cores, I had 5 servers identified by the core and re-used. I did > this as I understood instantiating a new server for every request was > expensive > > Thanks > Jay >
