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-17150: Create MemAllowedLimit #2708

Merged
merged 11 commits into from
Oct 7, 2024
Merged

Conversation

sigram
Copy link
Contributor

@sigram sigram commented Sep 12, 2024

This is a refreshed PR using the latest QueryLimit APIs and a thread-safe accumulation of value, similar to the approach in CpuAllowedLimit. However, since that class uses a thread-local managed by ThreadCpuTimer this implementation adds its own thread-local.

@github-actions github-actions bot added documentation Improvements or additions to documentation client:solrj tests cat:search labels Sep 12, 2024
Copy link
Contributor

@gus-asf gus-asf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lack of doc leaves me with some doubt as to the efficacy of my review. Biggest suggestion is to add Javadoc and clarify the asciidoc

@sigram sigram requested a review from gus-asf October 1, 2024 15:48
* Enforces a memory-based limit on a given SolrQueryRequest, as specified by the {@code memAllowed}
* query parameter.
*
* <p>This class tracks per-thread memory allocations using its own ThreadLocal. It records the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"per-thread memory allocations during a request using it's own Thread Local."

I think that phrase would give the gist without the reader needing to parse the following logic.

initAndGetCurrentAllocatedBytes();
}

private long initAndGetCurrentAllocatedBytes() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Methods called in constructors should be final.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is private, nothing can override it.

@@ -99,9 +136,8 @@ public boolean shouldExit() {
}

try {
long currentAllocatedBytes = (Long) GET_BYTES_METHOD.invoke(threadBean);
long currentAllocatedBytes = initAndGetCurrentAllocatedBytes();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like you should have an init() method (or just code in the constructor), and a getCurrentAllocatedBytes() method and thus avoid all init logic in subsequent calls? I believe Java guarantees that nothing calls methods on an object until the constructor completes.

@sigram sigram merged commit 5e231f7 into apache:main Oct 7, 2024
4 checks passed
@sigram sigram deleted the jira/solr-17150-4 branch October 7, 2024 16:32
sigram added a commit to sigram/solr that referenced this pull request Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cat:search client:solrj documentation Improvements or additions to documentation tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants