Hi Chris, Thanks for the details..
Our use case is simple, we have standalone solr servers, and custom request handler (plugin) is already defined and working as expected. The ask is we have to enhance the functionality of the Custom Request handler by providing a update feature as part of the flow. Update would be to query all the documents and update 1 or 2 field with particular value. If we were to do the query and update from any other process.. it would be HTTP. For our use case the query and update would be local to the container, wanted to avoid HTTP. As per your suggestion let me explore SearchHandler/QueryComponent/SolrIndexSearcher for our use case. Thanks Rajan From: Chris Hostetter <hossman_luc...@fucit.org> Date: Tuesday, 6 December 2022 at 12:34 AM To: users@solr.apache.org <users@solr.apache.org> Subject: Re: [External] : Re: Querying Solr Locally through Java API without using HttpClient : POC would be to add a function in the plugin.. which would query all the : documents locally (Say 100+ Million Documents) and update 1 or 2 fields : with a particular value. : : As the plugin would be local to this core.. wanted to avoid HTTP calls. I'm assuming here that you mean you want to write a *Solr* plugin (ie: A RequestHandler, SearchCOmponent, etc...) and from that code do a "query" to find documents. In no circumstances would i suggest that using EmbeddedSolrServer, inside of a real solr server, is a good idea. If you need your plugin to run on a single core, and iterate over docs from all shards, then you're going to need to make some sort of network call -- this is what things like the SearchHandler/QueryComponent do. If you are ok with your plugin only handling the "local" docs, then you can just talk to the SolrIndexSearcher direcly -- the way things like the QueryComponent do in distrib=false mode. If you also planning to *update* these docs, then you're going to need to be very careful in your code to check if you are running on the leader cores of each replica, so you don't have multiple replicas trying to make the same updates (you'll also need some way to ensure that your plugin gets "executed" on every leader (ie: running on every shard leader is a requirement, not just a liimiation) But ultimatley you've asked a very vague question about a very complicated concept -- and i would urge you to take a step back, describe your actual use cases (how are the documents selected? what kinds of updates are you doing? when will this plugin run? etc...) in more details so more useful/specific advice can be given... https://urldefense.com/v3/__https://people.apache.org/*hossman/*xyproblem__;fiM!!ACWV5N9M2RV99hQ!MLkq3YJRJnIzzbrVipDHb9q7KvQPp4Gx-pBknk6v63vknBNcpzMIC1X0q9Wo9z_7DxkeG9X6iMBTDTVOmpCIzI4WOOnTfcFbNaQ$<https://urldefense.com/v3/__https:/people.apache.org/*hossman/*xyproblem__;fiM!!ACWV5N9M2RV99hQ!MLkq3YJRJnIzzbrVipDHb9q7KvQPp4Gx-pBknk6v63vknBNcpzMIC1X0q9Wo9z_7DxkeG9X6iMBTDTVOmpCIzI4WOOnTfcFbNaQ$> XY Problem Your question appears to be an "XY Problem" ... that is: you are dealing with "X", you are assuming "Y" will help you, and you are asking about "Y" without giving more details about the "X" so that we can understand the full issue. Perhaps the best solution doesn't involve "Y" at all? See Also: https://urldefense.com/v3/__http://www.perlmonks.org/index.pl?node_id=542341__;!!ACWV5N9M2RV99hQ!MLkq3YJRJnIzzbrVipDHb9q7KvQPp4Gx-pBknk6v63vknBNcpzMIC1X0q9Wo9z_7DxkeG9X6iMBTDTVOmpCIzI4WOOnTJ-PoMR8$<https://urldefense.com/v3/__http:/www.perlmonks.org/index.pl?node_id=542341__;!!ACWV5N9M2RV99hQ!MLkq3YJRJnIzzbrVipDHb9q7KvQPp4Gx-pBknk6v63vknBNcpzMIC1X0q9Wo9z_7DxkeG9X6iMBTDTVOmpCIzI4WOOnTJ-PoMR8$> -Hoss https://urldefense.com/v3/__http://www.lucidworks.com/__;!!ACWV5N9M2RV99hQ!MLkq3YJRJnIzzbrVipDHb9q7KvQPp4Gx-pBknk6v63vknBNcpzMIC1X0q9Wo9z_7DxkeG9X6iMBTDTVOmpCIzI4WOOnT_SdGbsQ$<https://urldefense.com/v3/__http:/www.lucidworks.com/__;!!ACWV5N9M2RV99hQ!MLkq3YJRJnIzzbrVipDHb9q7KvQPp4Gx-pBknk6v63vknBNcpzMIC1X0q9Wo9z_7DxkeG9X6iMBTDTVOmpCIzI4WOOnT_SdGbsQ$>
