Hi, I would advise you to get involved in the SolrCloud initiative (see http://wiki.apache.org/solr/SolrCloud) and start designing a native indexing distributor component.
I envision something like an integration in UpdateHandler which knows about all collections and shards from ZK config, and is responsible for distributing incoming documents into the correct shard of the given collection, based on a pluggable DocShardingPolicy. The default DocShardingPolicy could be HashBasedDocShardingPolicy, and more can be implemented later. The benefit of implementing this "behind" the UpdateRequestHandlers is that you can use any old familiar Solr API to post documents to a distributed index without inventing a new web service. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com On 12. okt. 2010, at 21.11, bbarani wrote: > > Hi, > > I am thinking of creating a webservice for performing push indexing across > multiple solr instance. > > This is our SOLR configuration > > 3 Master instance ---> 3 slave instance. > > Each master maintains index of a particular item type. > > This is my idea.. > > We have a update UI which will push the SOLR XML to the web service > (whenever user inserts / update the data) and the web service will inturn > push the document to corresponding SOLR instance. Web service maintains the > mapping of item type and solr instance to which that particular data needs > to be indexed, the type is passed as an argument to web service. > > Just want to check if anyone has tried similar proces before? I am little > bit worried about scalability / also I am not sure how to implement an > approach when 2 users are trying to update the SOLR index at same time...I > know SOLR wont do queuing hence only one XML will be indexed and the other > wont get indexed.. > > Thanks, > Barani > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Webservice-for-push-indexing-tp1689864p1689864.html > Sent from the Solr - User mailing list archive at Nabble.com.
