Re: [I] Problems with istio and prometheus [solr-operator]
sukolenvo commented on issue #427: URL: https://github.com/apache/solr-operator/issues/427#issuecomment-2634253185 Can this issue be reopened please? appProtocol is not set in the latest operator: https://github.com/apache/solr-operator/blob/e1e4c2b3866581601b8e765139901447cb06cfa2/controllers/util/solr_util.go#L915 http2+headless service is not supported by istio and in our practice workaround of setting protocol to tcp shows good results. issue in istio: https://github.com/istio/istio/issues/49391#issuecomment-1954703454 As I understand previous fix of setting appProtocol to http caused was rolled back due to https://github.com/apache/solr-operator/issues/640 How about appProtocol: TCP? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [I] Problems with istio and prometheus [solr-operator]
sukolenvo commented on issue #427: URL: https://github.com/apache/solr-operator/issues/427#issuecomment-2635513779 BTW here is zookeeper operator headless service: all ports are prefixed with `tcp-` - one more option to consider ```yaml ports: - name: tcp-client port: 2181 protocol: TCP targetPort: 2181 - name: tcp-quorum port: 2888 protocol: TCP targetPort: 2888 - name: tcp-leader-election port: 3888 protocol: TCP targetPort: 3888 - name: tcp-metrics port: 7000 protocol: TCP targetPort: 7000 - name: tcp-admin-server port: 8080 protocol: TCP targetPort: 8080 ``` -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17582) CLUSTERSTATUS API could stream the response to save memory
[ https://issues.apache.org/jira/browse/SOLR-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923893#comment-17923893 ] ASF subversion and git services commented on SOLR-17582: Commit 5e328ee77e5858f4112e02652ddd4c8e14b6 in solr's branch refs/heads/main from Matthew Biscocho [ https://gitbox.apache.org/repos/asf?p=solr.git;h=5e328ee77e5 ] SOLR-17582: Stream CLUSTERSTATUS API for SolrJ version >= 9.9 (#3156) Or if unknown (e.g. some misc. HTTP/JSON). Co-authored-by: Matthew Biscocho > CLUSTERSTATUS API could stream the response to save memory > -- > > Key: SOLR-17582 > URL: https://issues.apache.org/jira/browse/SOLR-17582 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Priority: Minor > Labels: pull-request-available > Fix For: 9.9 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > The CLUSTERSTATUS API currently creates the entire response before submitting > it. If there are many thousands of collections, this will use up memory. It > could easily be modified to stream the response to compute each collection > information just-in-time. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17582: Stream CLUSTERSTATUS API for SolrJ version >= 9.9 [solr]
dsmiley merged PR #3156: URL: https://github.com/apache/solr/pull/3156 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17582) CLUSTERSTATUS API could stream the response to save memory
[ https://issues.apache.org/jira/browse/SOLR-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923898#comment-17923898 ] ASF subversion and git services commented on SOLR-17582: Commit dae9a93824124805b6b96700dab6037a737f40eb in solr's branch refs/heads/branch_9x from Matthew Biscocho [ https://gitbox.apache.org/repos/asf?p=solr.git;h=dae9a938241 ] SOLR-17582: Stream CLUSTERSTATUS API for SolrJ version >= 9.9 (#3156) Or if unknown (e.g. some misc. HTTP/JSON). Co-authored-by: Matthew Biscocho (cherry picked from commit 5e328ee77e5858f4112e02652ddd4c8e14b6) > CLUSTERSTATUS API could stream the response to save memory > -- > > Key: SOLR-17582 > URL: https://issues.apache.org/jira/browse/SOLR-17582 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Priority: Minor > Labels: pull-request-available > Fix For: 9.9 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > The CLUSTERSTATUS API currently creates the entire response before submitting > it. If there are many thousands of collections, this will use up memory. It > could easily be modified to stream the response to compute each collection > information just-in-time. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[PR] SOLR-17649: Fix Json faceting on multivalue number types [solr]
thomaswoeckinger opened a new pull request, #3158: URL: https://github.com/apache/solr/pull/3158 https://issues.apache.org/jira/browse/SOLR-17649 # Description FacetFieldProcessorByArrayDV can not handle fields with DocValues of type DocValuesType.SORTED_NUMERIC. If such a type is requested for faceting FacetFieldProcessorByHashDV must be used. # Solution Use the correct FacetFiledProcessor # Tests Create multi valued EnumFileds, which had DocValues enabled, to ensure the use of DocValuesType.SORTED_NUMERIC, index a few multivalued docs and query the facets afterwards # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation) - [ ] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17649) Multivalue facets on enum field type returns empty result when using JsonFacet
[
https://issues.apache.org/jira/browse/SOLR-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17649:
--
Labels: pull-request-available (was: )
> Multivalue facets on enum field type returns empty result when using JsonFacet
> --
>
> Key: SOLR-17649
> URL: https://issues.apache.org/jira/browse/SOLR-17649
> Project: Solr
> Issue Type: Bug
> Components: Facet Module, FacetComponent, faceting
>Affects Versions: 9.4, 9.5, 9.4.1, 9.6, 9.7, 9.6.1, 9.8
>Reporter: Thomas Wöckinger
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When using JsonFacet API on a multivalued EnumFieldType with facet method
> 'enum' the {color:#232629}FacetFieldProcessorByArrayDV{color} will be used.
> At line 96 ({color:#232629}FacetFieldProcessorByArrayDV.java){color} there is
> a check about allBuckets or missing buckets, which simply skip collect
> process.
> So at the moment there is no support for Multivalue faceting on facets which
> are using FacetFieldProcessorByArrayDV facet processor for collecting facets.
> Tested this behavior from 9.4 onwards, this feature was working on the 8.x
> releases.
> Multivalue faceting on EnumFieldType should be supported again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17651) Obfuscate System.exit(), remove direct usage
Houston Putman created SOLR-17651:
-
Summary: Obfuscate System.exit(), remove direct usage
Key: SOLR-17651
URL: https://issues.apache.org/jira/browse/SOLR-17651
Project: Solr
Issue Type: Improvement
Components: cli, Tests
Reporter: Houston Putman
In SOLR-17379, we are removing the {{TestSecurityManager}} defined in Lucene
that prohibits the usage of System.exit() in unit testing. This is important,
since gradle will fail with very little information when a test does a
System.exit() call.
In Solr, the CLI will use System.exit() to fail and show the user. This makes
sense as a CLI, but not in a unit test. It would be great if we could create a
utility that can be called in Solr to mimic System.exit(), but in unit testing
throw an exception instead. Then we could add System.exit() to forbidden-apis,
and ensure that our testing code won't run into this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17651) Obfuscate System.exit(), remove direct usage
[
https://issues.apache.org/jira/browse/SOLR-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-17651:
--
Status: Patch Available (was: Open)
> Obfuscate System.exit(), remove direct usage
>
>
> Key: SOLR-17651
> URL: https://issues.apache.org/jira/browse/SOLR-17651
> Project: Solr
> Issue Type: Improvement
> Components: cli, Tests
>Reporter: Houston Putman
>Priority: Major
>
> In SOLR-17379, we are removing the {{TestSecurityManager}} defined in Lucene
> that prohibits the usage of System.exit() in unit testing. This is important,
> since gradle will fail with very little information when a test does a
> System.exit() call.
> In Solr, the CLI will use System.exit() to fail and show the user. This makes
> sense as a CLI, but not in a unit test. It would be great if we could create
> a utility that can be called in Solr to mimic System.exit(), but in unit
> testing throw an exception instead. Then we could add System.exit() to
> forbidden-apis, and ensure that our testing code won't run into this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17651) Obfuscate System.exit(), remove direct usage
[
https://issues.apache.org/jira/browse/SOLR-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-17651:
--
Status: Open (was: Patch Available)
> Obfuscate System.exit(), remove direct usage
>
>
> Key: SOLR-17651
> URL: https://issues.apache.org/jira/browse/SOLR-17651
> Project: Solr
> Issue Type: Improvement
> Components: cli, Tests
>Reporter: Houston Putman
>Priority: Major
>
> In SOLR-17379, we are removing the {{TestSecurityManager}} defined in Lucene
> that prohibits the usage of System.exit() in unit testing. This is important,
> since gradle will fail with very little information when a test does a
> System.exit() call.
> In Solr, the CLI will use System.exit() to fail and show the user. This makes
> sense as a CLI, but not in a unit test. It would be great if we could create
> a utility that can be called in Solr to mimic System.exit(), but in unit
> testing throw an exception instead. Then we could add System.exit() to
> forbidden-apis, and ensure that our testing code won't run into this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17351: Decompose filestore "get file" API [solr]
gerlowskija commented on code in PR #3047:
URL: https://github.com/apache/solr/pull/3047#discussion_r1941803992
##
solr/core/src/java/org/apache/solr/filestore/NodeFileStore.java:
##
@@ -76,135 +66,54 @@ public SolrJerseyResponse getFile(String path, Boolean
sync, String getFrom, Boo
final var response = instantiateJerseyResponse(SolrJerseyResponse.class);
if (Boolean.TRUE.equals(sync)) {
- try {
-fileStore.syncToAllNodes(path);
-return response;
- } catch (IOException e) {
-throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "Error
getting file ", e);
- }
+ ClusterFileStore.syncToAllNodes(fileStore, path);
+ return response;
}
if (path == null) {
path = "";
}
final var pathCopy = path;
if (getFrom != null) {
- coreContainer
- .getUpdateShardHandler()
- .getUpdateExecutor()
- .submit(
- () -> {
-log.debug("Downloading file {}", pathCopy);
-try {
- fileStore.fetch(pathCopy, getFrom);
-} catch (Exception e) {
- log.error("Failed to download file: {}", pathCopy, e);
-}
-log.info("downloaded file: {}", pathCopy);
- });
+ ClusterFileStore.pullFileFromNode(coreContainer, fileStore, pathCopy,
getFrom);
return response;
}
FileStore.FileType type = fileStore.getType(path, false);
-if (type == FileStore.FileType.NOFILE) {
- final var fileMissingResponse =
- instantiateJerseyResponse(FileStoreDirectoryListingResponse.class);
- fileMissingResponse.files = Collections.singletonMap(path, null);
- return fileMissingResponse;
-}
-if (type == FileStore.FileType.DIRECTORY) {
- final var directoryListingResponse =
- instantiateJerseyResponse(FileStoreDirectoryListingResponse.class);
- final var directoryContents =
- fileStore.list(path, null).stream()
- .map(details -> convertToResponse(details))
- .collect(Collectors.toList());
- directoryListingResponse.files = Collections.singletonMap(path,
directoryContents);
- return directoryListingResponse;
+if (type == FileStore.FileType.NOFILE
+|| type == FileStore.FileType.DIRECTORY
+|| (type == FileStore.FileType.FILE && Boolean.TRUE.equals(meta))) {
+ return ClusterFileStore.getMetadata(type, path, fileStore);
}
-if (Boolean.TRUE.equals(meta)) {
- if (type == FileStore.FileType.FILE) {
-int idx = path.lastIndexOf('/');
-String fileName = path.substring(idx + 1);
-String parentPath = path.substring(0, path.lastIndexOf('/'));
-List l = fileStore.list(parentPath, s ->
s.equals(fileName));
-final var fileMetaResponse =
-instantiateJerseyResponse(FileStoreDirectoryListingResponse.class);
-fileMetaResponse.files =
-Collections.singletonMap(path, l.isEmpty() ? null :
convertToResponse(l.get(0)));
-return fileMetaResponse;
- }
-} else { // User wants to get the "raw" file
- // TODO Should we be trying to json-ify otherwise "raw" files in this
way? It seems like a
- // pretty sketchy idea, esp. for code with very little test coverage.
Consider removing
- if ("json".equals(req.getParams().get(CommonParams.WT))) {
-final var jsonResponse =
instantiateJerseyResponse(FileStoreJsonFileResponse.class);
-try {
- fileStore.get(
- pathCopy,
- it -> {
-try {
- InputStream inputStream = it.getInputStream();
- if (inputStream != null) {
-jsonResponse.response = new
String(inputStream.readAllBytes(), UTF_8);
- }
-} catch (IOException e) {
- throw new SolrException(
- SolrException.ErrorCode.SERVER_ERROR, "Error reading
file " + pathCopy);
+// User wants to get the "raw" file
+// TODO Should we be trying to json-ify otherwise "raw" files in this way?
It seems like a
Review Comment:
There's no discussion of it either in the PR or the JIRA that introduced it
(unless I'm missing something?). My guess is that it was an attempt at
convenience?
In any case; I think this entire file can now go. See my comment
[above](https://github.com/apache/solr/pull/3047/files#r1929771967) for more
details.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apa
[jira] [Created] (SOLR-17653) New DockerSolrServerTestRule that uses TestContainers/Docker
David Smiley created SOLR-17653:
---
Summary: New DockerSolrServerTestRule that uses
TestContainers/Docker
Key: SOLR-17653
URL: https://issues.apache.org/jira/browse/SOLR-17653
Project: Solr
Issue Type: Test
Components: SolrJ, test-framework
Reporter: David Smiley
We've got a {{SolrClientTestRule}} abstraction in our test infrastructure that
makes it easy for a test to work with Solr in an abstracted sense, using a
SolrClient to talk to it. This issue proposes a new implementation that uses
an Http SolrClient (of configurable implementation) to talk to SolrCloud
(embedded ZK) running on a single node in a Docker container, and using
TestContainers to facilitate the integration. Future extensibility: the
implementation could consider multiple nodes thus multiple containers. The
location of this utility could be a new artifact (JAR) living in the docker
module with appropriate dependencies, or just put in solr-test-framework.
This would be extremely useful! We could then write a hello-world SolrJ
SolrCloud test in which Solr is running semi-realistically. This is all we
need for easily adding some backwards-compatibility tests, in either direction
(SolrJ 9 to Solr 10, and SolrJ 10 to Solr 9). Both directions are useful in a
rolling upgrade. Tests using this in our test suite should be demarcated /
separated somehow so that running such tests is opt-in, not part of the "check"
task.
The addition of this may draw into question the validity/utility of our Docker
bats tests, that could perhaps instead be using this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17582: Stream CLUSTERSTATUS API for SolrJ version >= 9.9 [solr]
mlbiscoc commented on code in PR #3156: URL: https://github.com/apache/solr/pull/3156#discussion_r1941385619 ## solr/solrj/src/test/org/apache/solr/client/solrj/impl/ClusterStateProviderTest.java: ## Review Comment: Understood. Would you prefer I just remove these backwards compatibility tests I wrote? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17649) Multivalue facets on enum field type returns empty result when using JsonFacet
[
https://issues.apache.org/jira/browse/SOLR-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923794#comment-17923794
]
Thomas Wöckinger commented on SOLR-17649:
-
[~krisden] as you are one of the last commiters, you may have a look at pull
request
> Multivalue facets on enum field type returns empty result when using JsonFacet
> --
>
> Key: SOLR-17649
> URL: https://issues.apache.org/jira/browse/SOLR-17649
> Project: Solr
> Issue Type: Bug
> Components: Facet Module, FacetComponent, faceting
>Affects Versions: 9.4, 9.5, 9.4.1, 9.6, 9.7, 9.6.1, 9.8
>Reporter: Thomas Wöckinger
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When using JsonFacet API on a multivalued EnumFieldType with facet method
> 'enum' the {color:#232629}FacetFieldProcessorByArrayDV{color} will be used.
> At line 96 ({color:#232629}FacetFieldProcessorByArrayDV.java){color} there is
> a check about allBuckets or missing buckets, which simply skip collect
> process.
> So at the moment there is no support for Multivalue faceting on facets which
> are using FacetFieldProcessorByArrayDV facet processor for collecting facets.
> Tested this behavior from 9.4 onwards, this feature was working on the 8.x
> releases.
> Multivalue faceting on EnumFieldType should be supported again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17649: Fix Json faceting on multivalue number types [solr]
thomaswoeckinger commented on PR #3158: URL: https://github.com/apache/solr/pull/3158#issuecomment-2634739177 @risdenk as your are one of the last commiters in this area, you may have a look at this PR -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17631: Upgrade main to Lucene 10.x [solr]
cpoerschke commented on code in PR #3053:
URL: https://github.com/apache/solr/pull/3053#discussion_r1941767347
##
solr/core/src/java/org/apache/solr/search/Grouping.java:
##
@@ -603,7 +566,7 @@ protected Integer getNumberOfGroups() {
protected void populateScoresIfNecessary() throws IOException {
if (needScores) {
for (GroupDocs groups : result.groups) {
- TopFieldCollector.populateScores(groups.scoreDocs, searcher, query);
+ TopFieldCollector.populateScores(groups.scoreDocs(), searcher,
query);
Review Comment:
Just leaving a note here from investigating the grouping-related test
failures, the filling in of the scores here does not influence the `maxScore`
of a group and that seems to be wrong (always 1 possibly?) and so the groups
are ordered wrongly.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17379: Fix date parsing in Java 23, remove Lucene TestSecurityManager [solr]
HoustonPutman commented on PR #3154: URL: https://github.com/apache/solr/pull/3154#issuecomment-2634894329 > LGTM. Bit confused why BasicAuthIntegrationTest ever passed, but I'm sure you fix did it! It worked because it just logged an error, it didn't fail the test. Pretty weird, but oh well. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17379: Fix date parsing in Java 23, remove Lucene TestSecurityManager [solr]
HoustonPutman commented on code in PR #3154:
URL: https://github.com/apache/solr/pull/3154#discussion_r1941784747
##
solr/core/src/test/org/apache/solr/security/BasicAuthIntegrationTest.java:
##
@@ -295,12 +295,12 @@ public void testBasicAuth() throws Exception {
verifySecurityStatus(cl, baseUrl + "/admin/info/key", "key",
NOT_NULL_PREDICATE, 20);
assertAuthMetricsMinimums(17, 8, 8, 1, 0, 0);
- String[] toolArgs = new String[] {"status", "--solr-url", baseUrl};
+ String[] toolArgs =
+ new String[] {"status", "--solr-url", baseUrl, "--credentials",
"harry:HarryIsUberCool"};
ByteArrayOutputStream baos = new ByteArrayOutputStream();
PrintStream stdoutSim = new PrintStream(baos, true,
StandardCharsets.UTF_8.name());
StatusTool tool = new StatusTool(stdoutSim);
try {
-System.setProperty("basicauth", "harry:HarryIsUberCool");
Review Comment:
I have no idea, clearly it didn't work haha.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923812#comment-17923812
]
ASF subversion and git services commented on SOLR-17379:
Commit b779ed0590e36f69f7d1ce17e99dc936ab46752f in solr's branch
refs/heads/main from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=b779ed0590e ]
SOLR-17379: Fix date parsing in Java 23, remove Lucene TestSecurityManager
(#3154)
* Fix system exit in test
Co-authored-by: Chris Hostetter
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
>Reporter: Chris M. Hostetter
>Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17379: Fix date parsing in Java 23, remove Lucene TestSecurityManager [solr]
HoustonPutman merged PR #3154: URL: https://github.com/apache/solr/pull/3154 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923813#comment-17923813
]
Houston Putman commented on SOLR-17379:
---
We have System.exit() used in Solr, mainly in the CLI code. But it would be
great to create a convenience method in Solr that does a System.exit() when
running as an application and throws an exception when running as a unit test.
Then we could forbidden-apis System.exit(), and not have to rely on the
TestSecurityManager's mechanics. I'll file another ticket for that.
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
>Reporter: Chris M. Hostetter
>Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-14903) SolrCloud tests should use the jetty.xml that we ship with
[ https://issues.apache.org/jira/browse/SOLR-14903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-14903. - Resolution: Not A Problem I'm closing this because we already have such real jetty.xml testing via our Docker tests. Ironically that arrived in our project on the same month that this issue was filed yet we didn't point out it's a non-issue then. Not sure if "Fixed" vs "Not A Problem" but I chose the latter. RE TestContainers: I intend to file an issue now > SolrCloud tests should use the jetty.xml that we ship with > -- > > Key: SOLR-14903 > URL: https://issues.apache.org/jira/browse/SOLR-14903 > Project: Solr > Issue Type: Improvement >Reporter: Chris M. Hostetter >Assignee: Chris M. Hostetter >Priority: Major > Attachments: SOLR-14903.patch > > > writing a good test for SOLR-14898 turned out to be a challenge because > SolrCloudTestCase -- and any test using jetty -- doesn't _actually_ use the > jetty.xml that real Solr nodes use, because JettySolrRunner manually > configures i'ts jetty "Server" instance. > We should fix this so what you get i na test matches what a real Solr node > does. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17582: Stream CLUSTERSTATUS API for SolrJ version >= 9.9 [solr]
dsmiley commented on code in PR #3156: URL: https://github.com/apache/solr/pull/3156#discussion_r1941999333 ## solr/solrj/src/test/org/apache/solr/client/solrj/impl/ClusterStateProviderTest.java: ## Review Comment: They have value; they should stay. If we finally get the backwards-compatibility tests, we could remove them then. I filed https://issues.apache.org/jira/browse/SOLR-17653 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17632: Text to Vector Update Request Processor [solr]
dsmiley commented on code in PR #3151:
URL: https://github.com/apache/solr/pull/3151#discussion_r1942178207
##
solr/modules/llm/src/java/org/apache/solr/llm/texttovector/update/processor/TextToVectorUpdateProcessorFactory.java:
##
@@ -0,0 +1,97 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.llm.texttovector.update.processor;
+
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.params.SolrParams;
+import org.apache.solr.common.util.NamedList;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+import org.apache.solr.schema.DenseVectorField;
+import org.apache.solr.schema.FieldType;
+import org.apache.solr.schema.SchemaField;
+import org.apache.solr.update.processor.UpdateRequestProcessor;
+import org.apache.solr.update.processor.UpdateRequestProcessorFactory;
+
+/**
+ * This class implements an UpdateProcessorFactory for the Text To Vector
Update Processor.
+ */
+public class TextToVectorUpdateProcessorFactory extends
UpdateRequestProcessorFactory {
+private static final String INPUT_FIELD_PARAM = "inputField";
+private static final String OUTPUT_FIELD_PARAM = "outputField";
+private static final String MODEL_NAME = "model";
+
+String inputField;
+String outputField;
+String modelName;
+SolrParams params;
+
+
+@Override
+public void init(final NamedList args) {
+if (args != null) {
Review Comment:
args should never be null
##
solr/modules/llm/src/java/org/apache/solr/llm/texttovector/update/processor/TextToVectorUpdateProcessorFactory.java:
##
@@ -0,0 +1,97 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.llm.texttovector.update.processor;
+
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.params.SolrParams;
+import org.apache.solr.common.util.NamedList;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+import org.apache.solr.schema.DenseVectorField;
+import org.apache.solr.schema.FieldType;
+import org.apache.solr.schema.SchemaField;
+import org.apache.solr.update.processor.UpdateRequestProcessor;
+import org.apache.solr.update.processor.UpdateRequestProcessorFactory;
+
+/**
+ * This class implements an UpdateProcessorFactory for the Text To Vector
Update Processor.
+ */
+public class TextToVectorUpdateProcessorFactory extends
UpdateRequestProcessorFactory {
+private static final String INPUT_FIELD_PARAM = "inputField";
+private static final String OUTPUT_FIELD_PARAM = "outputField";
+private static final String MODEL_NAME = "model";
+
+String inputField;
+String outputField;
+String modelName;
+SolrParams params;
+
+
+@Override
+public void init(final NamedList args) {
+if (args != null) {
+params = args.toSolrParams();
+inputField = params.get(INPUT_FIELD_PARAM);
+checkNotNull(INPUT_FIELD_PARAM, inputField);
+
+outputField = params.get(OUTPUT_FIELD_PARAM);
+checkNotNull(OUTPUT_FIELD_PARAM, outputField);
+
+modelName = params.get(MODEL_NAME);
+checkNotNull(MODEL_NAME, modelName);
+}
+}
+
+private void checkNotNull(String paramName, Object param) {
+if (param == null) {
+throw new SolrException(
+SolrException.Er
[jira] [Commented] (SOLR-17635) javabin should deserialize maps as SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923909#comment-17923909 ] David Smiley commented on SOLR-17635: - Yes Renato. The change should ultimately be very small. Should use EnvUtils.getPropertyAsBoolean with something like "solr.solrj.javabin.mapAsNamedList" as a default, but possibly configurable directly in code if desired (e.g. for test or user's needs). > javabin should deserialize maps as SimpleOrderedMap > --- > > Key: SOLR-17635 > URL: https://issues.apache.org/jira/browse/SOLR-17635 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Priority: Major > > Once SimpleOrderedMap actually implements Map (SOLR-17623), Solr's "javabin" > format should deserialize all maps as a SimpleOrderedMap. This will make it > easier to transition away from NamedList/SimpleOrderedMap in responses (such > as to a Map or MapWriter) without worry of impacting javabin clients that > still expect a NamedList. > It may also increase deserialization performance & lower memory at the > expense of any former Maps (thus were deserialized as LinkedHashMap, O(1) > lookup) becoming O(N) lookup. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17635) javabin should deserialize maps as SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-17635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923837#comment-17923837 ] Renato Haeberli commented on SOLR-17635: [~dsmiley] Here you are referring to the Classes starting with JavaBin such as JavaBinCodec, JavaBinUpdateRequestCodec, etc.? > javabin should deserialize maps as SimpleOrderedMap > --- > > Key: SOLR-17635 > URL: https://issues.apache.org/jira/browse/SOLR-17635 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Priority: Major > > Once SimpleOrderedMap actually implements Map (SOLR-17623), Solr's "javabin" > format should deserialize all maps as a SimpleOrderedMap. This will make it > easier to transition away from NamedList/SimpleOrderedMap in responses (such > as to a Map or MapWriter) without worry of impacting javabin clients that > still expect a NamedList. > It may also increase deserialization performance & lower memory at the > expense of any former Maps (thus were deserialized as LinkedHashMap, O(1) > lookup) becoming O(N) lookup. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17652) PULL replicas can be stuck permemantly in DOWN state if leader election takes too long
[
https://issues.apache.org/jira/browse/SOLR-17652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923822#comment-17923822
]
Chris M. Hostetter commented on SOLR-17652:
---
FYI, here's a way to demonstrate the bug using solr's example mode (commands
below is from 9x, commands need modified slightly to work on main)...
{noformat}
./solr/packaging/build/dev/bin/solr start -e cloud -noprompt
# Setup our collection and both types of replicas
curl -sS
'http://localhost:8983/solr/admin/collections?action=CREATE&name=techproducts&numShards=1&tlogReplicas=1&createNodeSet=localhost:7574_solr'
curl -sS
'http://localhost:8983/solr/admin/collections?action=ADDREPLICA&collection=techproducts&shard=shard1&node=localhost:8983_solr&type=PULL'
./solr/packaging/build/dev/bin/post -c techproducts
./solr/packaging/build/dev/example/exampledocs/*.xml
# shut down pod hosting TLOG leader
./solr/packaging/build/dev/bin/solr stop -p 7574
# stop & re-start pod hosting PULL replica (and embedded zk)
./solr/packaging/build/dev/bin/solr stop -p 8983
./solr/packaging/build/dev/bin/solr start --cloud -p 8983 --solr-home
"/home/hossman/lucene/solr/solr/packaging/build/dev/example/cloud/node1/solr"
--server-dir "/home/hossman/lucene/solr/solr/packaging/build/dev/server"
# Wait ~13 min (until you see an exception like the one above in the logs)
# Bring back the TLOG leader pod...
./solr/packaging/build/dev/bin/solr start --cloud -p 7574 --solr-home
"/home/hossman/lucene/solr/solr/packaging/build/dev/example/cloud/node2/solr"
--server-dir "/home/hossman/lucene/solr/solr/packaging/build/dev/server" -z
127.0.0.1:9983
# PULL replica will still stay DOWN forever
{noformat}
> PULL replicas can be stuck permemantly in DOWN state if leader election takes
> too long
> --
>
> Key: SOLR-17652
> URL: https://issues.apache.org/jira/browse/SOLR-17652
> Project: Solr
> Issue Type: Bug
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17652.patch
>
>
> A bug exists in {{ZkController}} that can cause PULL replicas to be
> permanently stuck in a DOWN state (such that even a core RELOAD can not fix
> it) if that PULL replica was initially loaded during a leader election that
> takes a significant amount of time.
>
> Details to follow in comments
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17652) PULL replicas can be stuck permemantly in DOWN state if leader election takes too long
[
https://issues.apache.org/jira/browse/SOLR-17652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-17652:
--
Attachment: SOLR-17652.patch
Status: Open (was: Open)
Every now and then over the past few years, I've heard vague rumors of weird
situations involving TLOG+PULL replica based collections after "catastrophic"
failure situations with a Solr cloud cluster's impacting the shard leader
(network partitions, disk errors on leader, multi-node failures, etc...).
Typically, once the underlying problem is dealt with, and the leader election
eventually "succeeds" (either on it's own after nodes get restarted, or
sometimes with a manual FORCELEADER) all of the replicas should eventually get
healthy again ... BUT! ... in some of these vague rumored situations, I'm told
there are occasionally PULL replicas that never recover no matter how much time
passes – which never really made sense to me since I know the recovery code
operates in an (exponential back off loop) and because the anecdotal reports
only ever described PULL replicas being affect – not TLOG replicas, but PULL
replicas should never really care which TLOG replica is the leader (They
recheck the current leader on every PULL attempt)
Today I was doing some experiments with PULL replicas, and reading through some
of the core initialization code, and I think i figured out where/how this kind
of bug can occur:
1. A node hosting a PULL replica gets restarted (as part of whatever broader
catastrophic problem impacts the cluster)
2. the PULL replica comes online while there is no elected leader
3. the leader election takes longer then ~13 min (due to whatever catastrophic
problem is still being dealt with, and/or slow TLOG replay on the leader)
...in this case, the PULL replica will be left in a "DOWN" and will never
attempt to recover.
The cause of this problem is code in {{ZkController.register(...)}} which
expects that it can do the following in sequence:
* {{joinElection(...)}} (If replica type is eligible)
* call {{getLeader(cloudDesc, leaderVoteWait + 60)}} to see if the current
replica is the leader
** If this call throws a SolrException, {{ZkController.register(...)}}
propagates the exception w/o any sort of retry.
For NRT or TLOG replicas, this logic is fine: We've triggered an election and
even if no other replicas come along and join the election, eventually we'll
recognize that we're the leader and put our props into the leader znode so we
can read them back. But in the case of a PULL replica, there is no guarantee
if/when another replica comes along to become the leader – so if that
{{getLeader(...)}} times out, we get a log message that looks like this...
{noformat}
2025-02-04 18:38:50.124 ERROR
(coreZkRegister-1-thread-3-processing-localhost:8983_solr
techproducts_shard1_replica_p3 techproducts shard1 core_node4) [c:techproducts
s:shard1 r:core_node4 x:techproducts_shard1_replica_p3 t:] o.a.s.c.ZkCon
troller Error getting leader from zk => org.apache.solr.common.SolrException:
Could not get leader props
at
org.apache.solr.cloud.ZkController.getLeaderProps(ZkController.java:1554)
org.apache.solr.common.SolrException: Could not get leader props
at
org.apache.solr.cloud.ZkController.getLeaderProps(ZkController.java:1554) ~[?:?]
at
org.apache.solr.cloud.ZkController.getLeaderProps(ZkController.java:1514) ~[?:?]
at org.apache.solr.cloud.ZkController.getLeader(ZkController.java:1456)
~[?:?]
at org.apache.solr.cloud.ZkController.register(ZkController.java:1318)
~[?:?]
at org.apache.solr.cloud.ZkController.register(ZkController.java:1229)
~[?:?]
at
org.apache.solr.core.ZkContainer.lambda$registerInZk$0(ZkContainer.java:208)
~[?:?]
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:380)
~[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: org.apache.zookeeper.KeeperException$NoNodeException:
KeeperErrorCode = NoNode for /collections/techproducts/leaders/shard1/leader
at
org.apache.zookeeper.KeeperException.create(KeeperException.java:117) ~[?:?]
at org.apache.zookeeper.KeeperException.create(KeeperException.java:53)
~[?:?]
at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1972) ~[?:?]
at
org.apache.solr.common.cloud.SolrZkClient.lambda$getData$6(SolrZkClient.java:452)
~[?:?]
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:70)
~[?:?]
at
org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:452) ~[?:?]
at
org.a
Re: [PR] SOLR-17447 : Support to early terminate a search based on maxHits per collector. [solr]
dsmiley commented on PR #2960: URL: https://github.com/apache/solr/pull/2960#issuecomment-2635055839 "caller" by the first definition you listed -- basically the client of Solr. I'll say "client". Not sure if we have disagreement or not. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15767) Include a core set of Prometheus alert rules for monitoring SolrCloud on K8s
[
https://issues.apache.org/jira/browse/SOLR-15767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-15767:
--
Labels: pull-request-available (was: )
> Include a core set of Prometheus alert rules for monitoring SolrCloud on K8s
>
>
> Key: SOLR-15767
> URL: https://issues.apache.org/jira/browse/SOLR-15767
> Project: Solr
> Issue Type: New Feature
> Components: contrib - prometheus-exporter
>Reporter: Timothy Potter
>Assignee: Timothy Potter
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> As promised in my ApacheCon talk (recording here:
> https://www.youtube.com/watch?v=mR_3bbqZSRg), I'd like to ship a core set of
> alerting rules for monitoring SolrCloud clusters specifically on Kubernetes.
> The basic guidance will be for users to import these rules into the
> Prometheus stack (which provides a {{PrometheusRule}} CRD). Users will need
> to adjust the thresholds for their specific uses (e.g. p95) and alert
> interval. Eventually, I'd like to have a starter runbook to accompany the
> alert rules, but not there yet.
> Also, it's important to realize that the Prometheus stack provides a core set
> of alerting rules for monitoring node and pod health, so the Solr specific
> set should be considered complementary to those and users will be expected to
> use both sets, see:
> https://github.com/prometheus-operator/kube-prometheus/blob/0821adabf6f9f7aebf9343ecb07707826ce693ee/manifests/kubernetes-prometheusRule.yaml
> If users are not running in Kubernetes or not using the Prometheus stack, the
> rules should still be useful as a getting started guide on what to monitor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-15767: Prometheus alert rules for monitoring SolrCloud clusters on Kubernetes [solr]
janhoy commented on PR #395: URL: https://github.com/apache/solr/pull/395#issuecomment-2634109711 @thelabdude Picking up this again. First question: Would this rule set find a better home in solr-operator git repo? It could be part of helm template for rules to install as default, and we could have a values.yaml value for enabling/disabling, in case user wants to override. The rules could live in this repo, but then we'd have to copy/paste if we also want them to be ootb for solr-operator. For a customer Also, we could start writing a runbook for the standard alerts, it could either be a new chapter in the reference guide or just a markdown page inside prometheus-exporter folder that we could link to GitHub? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-15767: Prometheus alert rules for monitoring SolrCloud clusters on Kubernetes [solr]
solrbot commented on PR #395: URL: https://github.com/apache/solr/pull/395#issuecomment-2634107231 @thelabdude Picking up this again. First question: Would this rule set find a better home in solr-operator git repo? It could be part of helm template for rules to install as default, and we could have a values.yaml value for enabling/disabling, in case user wants to override. The rules could live in this repo, but then we'd have to copy/paste if we also want them to be ootb for solr-operator. For a customer Also, we could start writing a runbook for the standard alerts, it could either be a new chapter in the reference guide or just a markdown page inside prometheus-exporter folder that we could link to GitHub? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
