New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SOLR-10470: setParallelCacheRefreshes should be deprecated in favor of SolrClientBuilder methods #1248
Conversation
So, with these changes, a lot of tests fail... For example "DistributedExpandComponentTest" |
So... I can't get a clean run of tests on any branch of solr on my laptop.... |
So, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts on eliminating it?
I think it's preferable to make tuning settings settable instead of being hard-coded. That said, maybe it could be a global setting with a system property if it's expert enough. I'm +1 to doing that. Maybe solr.cloudSolrClient.parallelCacheRefreshLocks
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudHttp2SolrClient.java
Outdated
Show resolved
Hide resolved
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudHttp2SolrClient.java
Outdated
Show resolved
Hide resolved
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudHttp2SolrClient.java
Outdated
Show resolved
Hide resolved
/** | ||
* If caches are expired they are refreshed after acquiring a lock. This method sets the number of | ||
* locks. It is used by the Builder only. | ||
*/ | ||
void setParallelCacheRefreshesLocks(int parallelCacheRefreshesLocks) { | ||
locks = objectList(parallelCacheRefreshesLocks); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see this used by the builder, I see it used by the constructor. I think we don't need this method; it could be inline'ed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was looking for a place to put this observation, so I'll leave it here. I think I would prefer having a method that takes an 'int' and hides away the implementation. this would allow in the future for replacing this cache striping with another cache that also allows for setting the stripe size without breaking any clients that rely on this (if ever).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would prefer having a method that takes an 'int' and hides away the implementation.
That exists in this PR -- Builder.setParallelCacheRefreshes
. This makes the method I'm commenting on,
Builder.setParallelCacheRefreshesLocks
more dubious as to if it's needed/useful.
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudSolrClient.java
Show resolved
Hide resolved
left a few minor comments, overall this looks good. is updating the |
There are a lot of places where some clean up would be nice. I think we should add a new JIRA for these clean ups. I think it's an opportunity to see if there are any otehr java cleanups that could be done. |
…p2SolrClient.java Co-authored-by: David Smiley <dsmiley@apache.org>
I think I've responded to everythign from @dsmiley and @stillalex.. Only change I haven't made is to eliminate this property and replace it with a system variable... That feels like a bit more work, cause then I have to add more docs to ref guide etc... I can live iwth just moving it.... Thoughts? Should we not move forward with this PR and just add the system propertly? |
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudHttp2SolrClient.java
Show resolved
Hide resolved
I agree eliminating the property is more work. I don't have a preference here. I would add the system property support (left a comment at the relevant line) and not remove builder support yet. basically allow both options, just my 2 cents. |
I don't think we need to document expert/advanced things in the reference guide like this. I'm not saying there shouldn't be any such there, only that we should not be compelled to. |
@stillalex I created https://issues.apache.org/jira/browse/SOLR-16600 to track your idea, love a PR! |
I just fixed the lint problem. While it would be good to think about what properties should be settable and which should be system properties, I actually am thinking that is out of scope. I'd rather do that as a seperate PR, and where we think about ALL the properties and if they are system property settable.. (I also want to get Solr to a better way of handling property setting globablly anyway... ). So if you'all can live with it, I'd like to merge this as is.... @stillalex I added a JIRA for the simplification idea you had... |
Okay, any angst to me merging this? |
looks good to me, will leave @dsmiley to add any concerns if any. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay with me to delay System property use. But I'm dubious of a big grand over-haul all at once happening. Incremental progress vs grand over-haul.
FYI there's an interesting JIRA https://issues.apache.org/jira/browse/SOLR-15960 somewhat related and a colleague has been working on it slowly.
/** | ||
* If caches are expired they are refreshed after acquiring a lock. This method sets the number of | ||
* locks. It is used by the Builder only. | ||
*/ | ||
void setParallelCacheRefreshesLocks(int parallelCacheRefreshesLocks) { | ||
locks = objectList(parallelCacheRefreshesLocks); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would prefer having a method that takes an 'int' and hides away the implementation.
That exists in this PR -- Builder.setParallelCacheRefreshes
. This makes the method I'm commenting on,
Builder.setParallelCacheRefreshesLocks
more dubious as to if it's needed/useful.
Avoid solving naming confusion by just inlining the method in the one place we use it!
thanks for the comments folks. Running a full test, and waiting for the jenkins main branch to finish, and then will merge this. |
…f SolrClientBuilder methods (#1248) Introduce Builder setter for parallelCacheRefreshes on cloud SolrClients. Deprecated direct setter setParallelCacheRefreshes on cloud SolrClients. Inlined logic for creating object locks.
https://issues.apache.org/jira/browse/SOLR-10470
Description
setParallelCacheRefreshes should be deprecated in favor of SolrClientBuilder methods
Solution
Please provide a short description of the approach taken to implement your solution.