[GitHub] [lucene-solr] chatman commented on pull request #1684: SOLR-14613: strongly typed placement plugin interface and implementation

[GitBox <gi...@apache.org>]

chatman commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-686308531


   > You need to make a realistic proposal here IMO @noblepaul.
   > And we need something that already exists. If placement plugins depend on some
   > future rehaul of configuration in SolrCloud, we're pushing this way out because
   > from past discussion there doesn't seem to be a consensus on how/if to 
   > remove solr.xml and how to support its features differently.
   
   Noble has made an instructive example of how to deal with configuration properly (using clusterprops.json, not solr.xml): https://github.com/apache/lucene-solr/pull/1813
   How much more hand holding do you need in order to do the right thing? If you want solr.xml to go away completely before using clusterprops, then let us wait until that is done. Using solr.xml (per node config) for a cluster wide replica assignment policy is not acceptable. The reasons have been stated many times, but I'm happy to do one more round and explain to you as simply or in as much detail as you would like.
   
   
   > I think use of solr.xml for this is pragmatic/realistic with the Solr we have today.
   
   This is absolutely untrue. Pragmatic/realistic is a joke. Using solr.xml means new configuration cannot take effect unless that file is hand-edited and node is restarted. Even bigger problem, in context of replica assignment/placement, is the possibility of different nodes having different configurations for the placement plugins, and hence cause cluster wide inconsistency.
   
   > And it's flexible -- can go on the node or in ZK as you desire, and can hold structured
   > information (not just a bag of name-value pairs). This matter can be improved in the future.
   
   Oh, my goodness! Such thinking is the reason why our project is in a total mess today. Putting solr.xml in ZK is a hack, which we don't need to carry forward any longer. Even though I have expressed my reluctant agreement to carry on with solr.xml for now and switch to clusterprops.json before release, such flawed reasoning in favour of using solr.xml pushes me towards -1'ing this issue on this basis.
   
   > the other one [requirement] was efficiency: being able to fetch ALL needed properties
   > from a remote Node at once 
   
   Efficiency is a matter of implementation, and not a characteristic of the interfaces.
   
   Lets look at two approaches where the plugin requests for 10 properties.
   
   Design 1 (your design): Interface contains 10 different classes for the 10 properties, and solr-core returns 10 different objects for those properties to the plugin.
   Design 2 (proper design): Interface contains 1 class containing (at least) 10 getter methods for those properties (all typed as Optional). Solr-core returns that 1 object containing those 10 optional values filled in.
   
   In terms of interface design, design 2 is clearly more efficient because it requires the creation of 10 less objects.
   Lets look at efficiency from implementation point of view.
   
   In the design 2, solr-core (on a remote node) can populate all properties in the same object (even if it needs 10 multi-threaded calls). If there are multiple nodes from where those 10 properties need to be fetched, the plugin can make n multi-threaded calls to n remote nodes and receive n objects (each containing those 10 properties that are needed).
   
   How is any of this inefficient?


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org