What Jack and Shalin said.... Jack's comments about leaders changing is absolutely correct, although practically they won't change all that often unless you're bouncing nodes all over the place.
But as Shalin says, CloudSolrServer will already to this, at least as far as sending updates to a leader. If you only have one shard, it's already been done for you, just use SolrJ and CloudSolrServer. And https://issues.apache.org/jira/browse/SOLR-4816 will further refine the process such that the documents are split up into packets, all the docs for that packet go to the same shard, and the packet will be sent to the shard leader. So as Jack says, this is probably a really poor place to put _your_ development efforts since a> in the single-shard case it's already been done for you and b> in the near future it'll already have been done for you in the multi-shard case. If you want to pursue this, I suggest putting your efforts into helping test SOLR-4816 is both more efficient for you and a help to the larger community. Best Erick On Sun, Jul 7, 2013 at 2:52 AM, Shalin Shekhar Mangar <shalinman...@gmail.com> wrote: > Update requests are routed only to leader nodes by CloudSolrServer so > there is a 1/numShards probability of avoiding an extra network hop. > It is *not* a 1/(number of nodes in cluster) probability as you may > think. > > You may also be interested in > https://issues.apache.org/jira/browse/SOLR-4816 . Perhaps you can try > the patch and report your results. > > On Sun, Jul 7, 2013 at 11:18 AM, Jack Krupansky <j...@basetechnology.com> > wrote: >> There are three "concepts" to grasp: >> >> 1. You can send Solr update requests to ANY node of the cluster. Period. >> 2. Any extra network traffic (within the cluster) is likely to be negligible >> and absolutely not worrying about unless you have definitive evidence to the >> contrary. >> 3. Leader nodes in SolrCloud are designed to be dynamic and will change over >> time. Generally, you won't know which node is the leader for a shard at any >> given moment - it may have been a particular node one milliscond ago, but >> now maybe another node has been designated as the leader. Neither the >> application nor the user designates which node is a leader for a shard - it >> is a dynamic election process. Sure, you can check to see which node is >> currently the leader, but one millisecond later some other node may have >> gotten elected to be the leader. >> >> To repeat, you DO NOT need to be concerned with sending Solr update requests >> to a shard "leader". The SolrCloud concept of "leader" is really only needed >> WITHIN the cluster. Clients outside of the SolrCloud cluster need not >> concern themselves with shard "leaders." >> >> "Micro-optimization" and "premature optimization" are very poor tools to >> lead a system design. Focus the energy on the data modeling and the overall >> application design. >> >> -- Jack Krupansky >> >> -----Original Message----- From: vicky desai >> Sent: Sunday, July 07, 2013 1:17 AM >> To: solr-user@lucene.apache.org >> Subject: Re: Is it possible to find a leader from a list of cores in solr >> via java code >> >> >> Hi Erik, >> >> I just wanted to clarify if u got my concern right. If i send some documents >> to the replica core wont it first have to send the documents to the leader >> core which in turn would be sending it back to the replica cores. If yes >> then this will lead to additional network traffic which can be avoided by >> sending the documents directly to leader. >> >> Please correct me if I have got the concept incorrect.Any help is >> appreciated >> >> >> Thanks, >> Vicky >> >> >> >> -- >> View this message in context: >> http://lucene.472066.n3.nabble.com/Is-it-possible-to-find-a-leader-from-a-list-of-cores-in-solr-via-java-code-tp4074994p4076016.html >> Sent from the Solr - User mailing list archive at Nabble.com. > > > > -- > Regards, > Shalin Shekhar Mangar.
