Skip to content
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

Merged
merged 9 commits into from Dec 31, 2022

Conversation

epugh
Copy link
Contributor

@epugh epugh commented Dec 22, 2022

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.

@epugh
Copy link
Contributor Author

epugh commented Dec 23, 2022

So, with these changes, a lot of tests fail... For example "DistributedExpandComponentTest"

@epugh
Copy link
Contributor Author

epugh commented Dec 23, 2022

So... I can't get a clean run of tests on any branch of solr on my laptop....

@epugh epugh requested a review from dsmiley December 23, 2022 16:47
@epugh
Copy link
Contributor Author

epugh commented Dec 23, 2022

So, setParallelCacheRefreshes appears to be a odd setting.... Does anyone actually change it/use it? Or do we all just use the default of 3? There don't appear to be any tests for it.... Thoughts on eliminating it?

Copy link
Contributor

@dsmiley dsmiley left a 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

Comment on lines 1233 to 1240
/**
* 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);
}

Copy link
Contributor

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.

Copy link
Member

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).

Copy link
Contributor

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.

@stillalex
Copy link
Member

left a few minor comments, overall this looks good.

is updating the objectList method on the table? I find this code a bit ugly (bigger change would be to use an array everywhere, list is not doing any favors. smaller change would be to at least return List instead of ArrayList)

@epugh
Copy link
Contributor Author

epugh commented Dec 27, 2022

left a few minor comments, overall this looks good.

is updating the objectList method on the table? I find this code a bit ugly (bigger change would be to use an array everywhere, list is not doing any favors. smaller change would be to at least return List instead of ArrayList)

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.

@epugh
Copy link
Contributor Author

epugh commented Dec 27, 2022

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?

@stillalex
Copy link
Member

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.

@dsmiley
Copy link
Contributor

dsmiley commented Dec 28, 2022

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.

@epugh
Copy link
Contributor Author

epugh commented Dec 29, 2022

left a few minor comments, overall this looks good.
is updating the objectList method on the table? I find this code a bit ugly (bigger change would be to use an array everywhere, list is not doing any favors. smaller change would be to at least return List instead of ArrayList)

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.

@stillalex I created https://issues.apache.org/jira/browse/SOLR-16600 to track your idea, love a PR!

@epugh
Copy link
Contributor Author

epugh commented Dec 29, 2022

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...

@epugh
Copy link
Contributor Author

epugh commented Dec 30, 2022

Okay, any angst to me merging this?

@stillalex
Copy link
Member

looks good to me, will leave @dsmiley to add any concerns if any.

Copy link
Contributor

@dsmiley dsmiley left a 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.

Comment on lines 1233 to 1240
/**
* 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);
}

Copy link
Contributor

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!
@epugh
Copy link
Contributor Author

epugh commented Dec 31, 2022

thanks for the comments folks. Running a full test, and waiting for the jenkins main branch to finish, and then will merge this.

@epugh epugh merged commit ac57877 into apache:main Dec 31, 2022
epugh added a commit that referenced this pull request Dec 31, 2022
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants