Re: [PR] feat(update-security-json): Update security.json when secret is updated [solr-operator]
mcarroll1 commented on code in PR #744:
URL: https://github.com/apache/solr-operator/pull/744#discussion_r1939622256
##
controllers/util/solr_security_util.go:
##
@@ -240,11 +245,16 @@ func cmdToPutSecurityJsonInZk() string {
cmd := " solr zk cp zk:/security.json /tmp/current_security.json
>/dev/null 2>&1; " +
" GET_CURRENT_SECURITY_JSON_EXIT_CODE=$?; " +
"if [ ${GET_CURRENT_SECURITY_JSON_EXIT_CODE} -eq 0 ]; then " +
// JSON already exists
- "if [ ! -s /tmp/current_security.json ] || grep -q '^{}$'
/tmp/current_security.json ]; then " + // File doesn't exist, is empty, or is
just '{}'
+ "if [ ! -s /tmp/current_security.json ] || grep -q '^{}$'
/tmp/current_security.json; then " + // File doesn't exist, is empty, or is
just '{}'
" echo $SECURITY_JSON > /tmp/security.json;" +
" solr zk cp /tmp/security.json zk:/security.json >/dev/null
2>&1; " +
" echo 'Blank security.json found. Put new security.json in
ZK'; " +
- "fi; " + // TODO: Consider checking a diff and still applying
over the top
+ "elif [ \"${SECURITY_JSON_OVERWRITE}\" = true ] && [ \"$(cat
/tmp/current_security.json)\" != \"$(echo $SECURITY_JSON)\" ]; then " + // We
want to overwrite the security config if there's a diff
Review Comment:
Agreed that this bit of bash could probably be optimized. I don't
immediately see a way of re-arranging the conditions. Maybe I can just create
function that takes "message" as an input?
--
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
[PR] SOLR-17582: Stream CLUSTERSTATUS API for SolrJ version >= 9.9 [solr]
mlbiscoc opened a new pull request, #3156: URL: https://github.com/apache/solr/pull/3156 https://issues.apache.org/jira/browse/SOLR-17582 # Description Check for SolrJ version from a cluster status request user agent header to stream the response for any SolrJ clients >= 9.9 allowing for backwards compatibility. # Solution Removed old Javabin check that didn't allow streaming for SolrJ and use the requests Solr version as the check instead for >= 9.9 to either stream or collect whole response in a `SimpleOrderedMap` # Tests Created `testClusterStateProviderBackwardCompatability` to test backwards compatability # 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] [Commented] (SOLR-17641) Support Java 24
[ https://issues.apache.org/jira/browse/SOLR-17641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923445#comment-17923445 ] David Smiley commented on SOLR-17641: - Please raise in dev list for visibility of a key decision like this > Support Java 24 > --- > > Key: SOLR-17641 > URL: https://issues.apache.org/jira/browse/SOLR-17641 > Project: Solr > Issue Type: Bug > Components: SolrCLI, Tests >Reporter: Houston Putman >Priority: Critical > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > The main thing here is to disable the Security Manager for Java 24+, both for > the CLI and testing. > Reference: https://github.com/apache/lucene/issues/14184 -- 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_r1940305756
##
solr/core/src/java/org/apache/solr/packagemanager/PackageManager.java:
##
@@ -173,7 +173,7 @@ public void uninstall(String packageName, String version)
String.format(Locale.ROOT, "/package/%s/%s/%s", packageName, version,
"manifest.json"));
for (String filePath : filesToDelete) {
DistribFileStore.deleteZKFileEntry(zkClient, filePath);
- String path = "/api/cluster/files" + filePath;
+ String path = "/api/cluster/filestore/files" + filePath;
Review Comment:
> Can a filestore have anything under than files?
It can: "metadata" and "commands" are both under the "filestore" path as
siblings to "files".
--
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-2632468777 Aha! Tracked it down to `BasicAuthIntegrationTest`. Wow these tests... -- 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-17351: Decompose filestore "get file" API [solr]
gerlowskija commented on code in PR #3047:
URL: https://github.com/apache/solr/pull/3047#discussion_r1940305043
##
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:
Not that I know of. I'm going to nuke it based on the discussion
[here](https://github.com/apache/solr/pull/3047/files#r1929771967), and that
might flush out something I don't understand.
(We'll need to make sure we're only deprecating it in the 9.x backport, but
that's not a big deal...)
--
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
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_r1940306565 ## solr/solr-ref-guide/modules/configuration-guide/pages/package-manager-internals.adoc: ## @@ -115,7 +115,7 @@ openssl dgst -sha1 -sign my_key.pem runtimelibs.jar | openssl enc -base64 | sed + [source, bash] -curl --data-binary @runtimelibs.jar -X PUT http://localhost:8983/api/cluster/files/mypkg/1.0/myplugins.jar?sig= +curl --data-binary @runtimelibs.jar -X PUT http://localhost:8983/api/cluster/filestore/files/mypkg/1.0/myplugins.jar?sig= Review Comment: (See other comments - "files" is our way to distinguish between "metadata" and "commands", which are both under the "/filestore" path.) -- 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-17497) Pull replicas throws AlreadyClosedException
[
https://issues.apache.org/jira/browse/SOLR-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923454#comment-17923454
]
Houston Putman commented on SOLR-17497:
---
Should we resolve this with a fix version?
> Pull replicas throws AlreadyClosedException
> -
>
> Key: SOLR-17497
> URL: https://issues.apache.org/jira/browse/SOLR-17497
> Project: Solr
> Issue Type: Task
>Reporter: Sanjay Dutt
>Priority: Major
> Attachments: Screenshot 2024-10-23 at 6.01.02 PM.png
>
>
> Recently, a common exception (org.apache.lucene.store.AlreadyClosedException:
> this Directory is closed) seen in multiple failed test cases.
> FAILED: org.apache.solr.cloud.TestPullReplica.testKillPullReplica
> FAILED:
> org.apache.solr.cloud.SplitShardWithNodeRoleTest.testSolrClusterWithNodeRoleWithPull
> FAILED: org.apache.solr.cloud.TestPullReplica.testAddDocs
>
>
> {code:java}
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an
> uncaught exception in thread: Thread[id=10271,
> name=fsyncService-6341-thread-1, state=RUNNABLE,
> group=TGRP-SplitShardWithNodeRoleTest]
> at
> __randomizedtesting.SeedInfo.seed([3F7DACB3BC44C3C4:E5DB3E97188A8EB9]:0)
> Caused by: org.apache.lucene.store.AlreadyClosedException: this Directory is
> closed
> at __randomizedtesting.SeedInfo.seed([3F7DACB3BC44C3C4]:0)
> at
> app//org.apache.lucene.store.BaseDirectory.ensureOpen(BaseDirectory.java:50)
> at
> app//org.apache.lucene.store.ByteBuffersDirectory.sync(ByteBuffersDirectory.java:237)
> at
> app//org.apache.lucene.tests.store.MockDirectoryWrapper.sync(MockDirectoryWrapper.java:214)
> at
> app//org.apache.solr.handler.IndexFetcher$DirectoryFile.sync(IndexFetcher.java:2034)
> at
> app//org.apache.solr.handler.IndexFetcher$FileFetcher.lambda$fetch$0(IndexFetcher.java:1803)
> at
> app//org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$1(ExecutorUtil.java:449)
> at
> java.base@11.0.24/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base@11.0.24/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base@11.0.24/java.lang.Thread.run(Thread.java:829)
> {code}
>
> Interesting thing about these test cases is that they all share same kind of
> setup where each has one shard and two replicas – one NRT and another is PULL.
>
> Going through one of the test case execution step.
> FAILED: org.apache.solr.cloud.TestPullReplica.testKillPullReplica
>
> Test flow
> 1. Create a collection with 1 NRT and 1 PULL replica
> 2. waitForState
> 3. waitForNumDocsInAllActiveReplicas(0); // *Name says it all*
> 4. Index another document.
> 5. waitForNumDocsInAllActiveReplicas(1);
> 6. Stop Pull replica
> 7. Index another document
> 8. waitForNumDocsInAllActiveReplicas(2);
> 9. Start Pull Replica
> 10. waitForState
> 11. waitForNumDocsInAllActiveReplicas(2);
>
> As per the logs the whole sequence executed successfully. Here is the link to
> the logs:
> [https://ge.apache.org/s/yxydiox3gvlf2/tests/task/:solr:core:test/details/org.apache.solr.cloud.TestPullReplica/testKillPullReplica/1/output]
> (link may stop working in the future)
>
> Last step where they are making sure that all the active replicas should have
> two documents each has logged a info which is another proof that it completed
> successfully.
>
> {code:java}
> 616575 INFO
> (TEST-TestPullReplica.testKillPullReplica-seed#[F30CC837FDD0DC28]) [n: c: s:
> r: x: t:] o.a.s.c.TestPullReplica Replica core_node3
> (https://127.0.0.1:35647/solr/pull_replica_test_kill_pull_replica_shard1_replica_n1/)
> has all 2 docs 616606 INFO (qtp1091538342-13057-null-11348)
> [n:127.0.0.1:38207_solr c:pull_replica_test_kill_pull_replica s:shard1
> r:core_node4 x:pull_replica_test_kill_pull_replica_shard1_replica_p2
> t:null-11348] o.a.s.c.S.Request webapp=/solr path=/select
> params={q=*:*&wt=javabin&version=2} rid=null-11348 hits=2 status=0 QTime=0
> 616607 INFO
> (TEST-TestPullReplica.testKillPullReplica-seed#[F30CC837FDD0DC28]) [n: c: s:
> r: x: t:] o.a.s.c.TestPullReplica Replica core_node4
> (https://127.0.0.1:38207/solr/pull_replica_test_kill_pull_replica_shard1_replica_p2/)
> has all 2 docs{code}
>
> *Where is the issue then?*
> In the logs it has been observed, that after restarting the PULL replica. The
> recovery process started and after fetching all the files info from the NRT,
> the replication aborted and logged "User aborted replication"
>
> {code:java}
> o.a.s.h.IndexFetcher User aborted Replication =>
> org.apache.solr.handler.IndexFetcher$ReplicationHandlerException: User
> aborted replication at
> org.apache.solr.handler.IndexFetch
[jira] [Commented] (SOLR-17641) Support Java 24
[ https://issues.apache.org/jira/browse/SOLR-17641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923453#comment-17923453 ] Houston Putman commented on SOLR-17641: --- I will raise it, but it's not really a decision. This is a must-do, the security manager doesn't exist in Java 24. There may be additional things we need to do in order to secure Solr to the standard we want. > Support Java 24 > --- > > Key: SOLR-17641 > URL: https://issues.apache.org/jira/browse/SOLR-17641 > Project: Solr > Issue Type: Bug > Components: SolrCLI, Tests >Reporter: Houston Putman >Priority: Critical > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > The main thing here is to disable the Security Manager for Java 24+, both for > the CLI and testing. > Reference: https://github.com/apache/lucene/issues/14184 -- 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 commented on PR #3154: URL: https://github.com/apache/solr/pull/3154#issuecomment-2632228099 This fails every time on Crave, because a grade test runner is returning an exit code of "1". This doesn't replicate for me, but it is suspicious given that `TestSecurityManager` does stuff around exit codes... Trying my best to replicate locally -- 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] [Created] (SOLR-17650) Determine executor for UpdateLog reading
Houston Putman created SOLR-17650: - Summary: Determine executor for UpdateLog reading Key: SOLR-17650 URL: https://issues.apache.org/jira/browse/SOLR-17650 Project: Solr Issue Type: Improvement Reporter: Houston Putman Currently most operations that read from the updateLog use the OrderedExecutor that is setup for that purpose. However, TLOG replicas, when taking leadership, read from the updateLog without the executor (using the inSortedOrder = true parameter). SOLR-17391 changed the default executor for updateLog reading to use a fixed coreSize thread pool, which seems like started to enable parallel reading of the updateLog (which was supposed to be true beforehand, but it looks like our understanding of the executor was wrong). This ticket's purpose is to: # Investigate the correct way of reading the updateLog using an executor # Determine if there needs to actually be multiple ways (inSortedOrder=true/false) # Make sure the tests pass with whatever we decide. -- 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-17650) Determine executor for UpdateLog reading
[
https://issues.apache.org/jira/browse/SOLR-17650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923488#comment-17923488
]
Houston Putman commented on SOLR-17650:
---
Currently the buffered update tests (
{{TestRecovery.testBufferedMultipleCalls}} , {{
TestRecovery.testBufferedMultipleCalls}} , {{TestRecovery.testDropBuffered}} )
are failing because of this executor change.
> Determine executor for UpdateLog reading
>
>
> Key: SOLR-17650
> URL: https://issues.apache.org/jira/browse/SOLR-17650
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Priority: Major
>
> Currently most operations that read from the updateLog use the
> OrderedExecutor that is setup for that purpose. However, TLOG replicas, when
> taking leadership, read from the updateLog without the executor (using the
> inSortedOrder = true parameter).
> SOLR-17391 changed the default executor for updateLog reading to use a fixed
> coreSize thread pool, which seems like started to enable parallel reading of
> the updateLog (which was supposed to be true beforehand, but it looks like
> our understanding of the executor was wrong).
> This ticket's purpose is to:
> # Investigate the correct way of reading the updateLog using an executor
> # Determine if there needs to actually be multiple ways
> (inSortedOrder=true/false)
> # Make sure the tests pass with whatever we decide.
--
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-17334) Minor bugs in Solr dedicated coordinator mode
[
https://issues.apache.org/jira/browse/SOLR-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923498#comment-17923498
]
David Smiley commented on SOLR-17334:
-
Neither linked PRs are merged. I think the code is good but lacks tests and
some energy to get it over the finish line. Closing this JIRA doesn't make
sense to me.
> Minor bugs in Solr dedicated coordinator mode
> -
>
> Key: SOLR-17334
> URL: https://issues.apache.org/jira/browse/SOLR-17334
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 9.6
>Reporter: Torsten Bøgh Köster
>Assignee: Noble Paul
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> We recently put dedicated Solr coordinator nodes into production and stumbled
> upon some minor bugs/improvements:
> - The Solr root resource cannot be requested on a coordinator node
> - Coordinator requests are enabled for the {{/select}} handler only
> - From outside proxied and coordinator requests cannot be distinguished
> h3. Solr root resource
> We adopted a general fix from the {{HttpSolrCall}} to check whether the given
> {{collectionName}} is {{{}null{}}}. This fixes requesting the root resource
> (and maybe other similar requests)
> h3. {{/select}} handler only
> Coordinator requests are limited to the {{/select}} handler. In our
> environment we make heavy usage of pre-configured Solr handlers. We could not
> find any reason to limit coordinator calls to the {{/select}} handler and
> removed the limitation.
> h3. Coordinator requests cannot be identified by Solr response
> With any Solr response you cannot distinguish coordinator from proxied (or
> regular) requests. While this is great for consistency it makes testing extra
> hard. We added an extra Solr header field with the coordinator node name
> called {{requestCoordinatorNode}} when debug is enabled. This eases testing
> and debugging a lot.
>
> A Pull Request is in the making!
--
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 commented on PR #3154: URL: https://github.com/apache/solr/pull/3154#issuecomment-2632284025 Nvm, replicated it locally. -- 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-17641: Disable the Security Manager for Java 24+ [solr]
madrob commented on PR #3153: URL: https://github.com/apache/solr/pull/3153#issuecomment-2632357157 Agree with @epugh - isn't Security Manager all no-ops even with 21 (which IIRC is the minimum Java for Solr 10) -- 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-17646) DirectoryFactory should support any NIO FileSystemProvider
[ https://issues.apache.org/jira/browse/SOLR-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923506#comment-17923506 ] David Smiley commented on SOLR-17646: - For sure, NIOFSDirectoryFactory, StandardDirectoryFactory, and CachingDirectoryFactory will need modifications, as I see usages of `Path.of` and other things that assumes the default FileSystem. Two ideas, not mutually exclusive: * the DirectoryFactory could have a URI configuration string that implies a certain FileSystem. Convert this to a Path in a few lines of code. Maybe need this _anyway_, if for nothing else, as a default. * the DF.create method could keep path being a String; doesn't have to be changed to a Path. Changing some Strings to a Path would be a big change; perhaps too much for this JIRA and not strictly necessary anyway TBH. As a string, it could be a URI and converted to a Path with a few lines of standard code. Hopefully this URI style data dir string would work if we configure a core to have such a data dir. The work here might start with a simple test using EmbeddedSolrServerTestRule configured to use NIOFSDirectoryFactory and attempting to use a built-in FileSystem like for Zip, even though read-only (I assume). It's plausible we don't _need_ to change some String to Paths; hard to say without digging into the work. It might be worthwhile to see if there is similar support in OpenSearch or something else to see what that looks like. > DirectoryFactory should support any NIO FileSystemProvider > -- > > Key: SOLR-17646 > URL: https://issues.apache.org/jira/browse/SOLR-17646 > Project: Solr > Issue Type: New Feature >Reporter: David Smiley >Priority: Major > > Ideally, the DirectoryFactory should support any NIO FileSystemProvider > without assuming the local/default FileSystem. There are a variety of > implementations out there, such as for cloud storage (S3, GCP, ...), > [HDFS|https://github.com/damiencarol/jsr203-hadoop], and even Zip (imagine a > read-only directory). This means switching from String & File to Path, and > avoiding sneaky methods that assume the default FileSystem. -- 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-17641) Support Java 24
[ https://issues.apache.org/jira/browse/SOLR-17641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923508#comment-17923508 ] Gus Heck commented on SOLR-17641: - Opensearch folks had a large discussion about the disappearance of the security manager... https://github.com/opensearch-project/OpenSearch/issues/1687 > Support Java 24 > --- > > Key: SOLR-17641 > URL: https://issues.apache.org/jira/browse/SOLR-17641 > Project: Solr > Issue Type: Bug > Components: SolrCLI, Tests >Reporter: Houston Putman >Priority: Critical > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > The main thing here is to disable the Security Manager for Java 24+, both for > the CLI and testing. > Reference: https://github.com/apache/lucene/issues/14184 -- 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]
epugh commented on code in PR #3154:
URL: https://github.com/apache/solr/pull/3154#discussion_r1940367902
##
solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java:
##
@@ -1064,43 +1065,37 @@ public void testAKSTZone() throws IOException {
final String inputString = "Thu Nov 13 04:35:51 AKST 2008"; // asctime +
timezone1
final long expectTs = 1226583351000L;
-assertEquals(
-expectTs,
-DateTimeFormatter.ofPattern(dateFormat, Locale.ENGLISH)
-.withZone(ZoneId.of("UTC"))
-.parse(inputString, Instant::from)
-.toEpochMilli());
-// ensure english locale and root locale return the same date
-assertEquals(
-expectTs + "",
-DateTimeFormatter.ofPattern(dateFormat, Locale.ENGLISH)
-.withZone(ZoneId.of("UTC"))
-.parse(inputString, Instant::from)
-.toEpochMilli(),
-DateTimeFormatter.ofPattern(dateFormat, Locale.ROOT)
-.withZone(ZoneId.of("UTC"))
-.parse(inputString, Instant::from)
-.toEpochMilli());
+try {
+ // ensure english locale and root locale return the same date
+ assertEquals(
+ expectTs,
+ DateTimeFormatter.ofPattern(dateFormat, Locale.ENGLISH)
+ .withZone(ZoneId.of("UTC"))
+ .parse(inputString, Instant::from)
+ .toEpochMilli());
+
+ assertEquals(
+ expectTs,
+ DateTimeFormatter.ofPattern(dateFormat, Locale.ROOT)
+ .withZone(ZoneId.of("UTC"))
+ .parse(inputString, Instant::from)
+ .toEpochMilli());
+} catch (DateTimeParseException e) {
+ // If the JVM's java.locale.providers can't parse these, there is no
hope of this test passing
+ assumeNoException("JVM's Locale provider is incompatible with this
test", e);
+}
assertParsedDate(
inputString,
Date.from(Instant.ofEpochMilli(expectTs)),
"parse-date-patterns-default-config");
-// A bug in Java 9 (not in 8) causes this to fail! (not fixed yet?!)
Review Comment:
nice clean up
##
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:
any chance that this pattern shows up anywhere else and or is suggested in
docs? Magic system variable?
--
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] feat(update-security-json): Update security.json when secret is updated [solr-operator]
mcarroll1 commented on code in PR #744:
URL: https://github.com/apache/solr-operator/pull/744#discussion_r1939586626
##
config/crd/bases/solr.apache.org_solrclouds.yaml:
##
@@ -10205,29 +10205,37 @@ spec:
description: |-
Configure a user-provided security.json from a secret to
allow for advanced security config.
If not specified, the operator bootstraps a
security.json with basic auth enabled.
- This is a bootstrapping config only; once Solr is
initialized, the security config should be managed by the security API.
properties:
- key:
-description: The key of the secret to select from.
Must be
- a valid secret key.
-type: string
- name:
-default: ""
+ bootstrapSecurityJson:
+description: SecretKeySelector selects a key of a
Secret.
+properties:
+ key:
+description: The key of the secret to select from.
Must
+ be a valid secret key.
+type: string
+ name:
+default: ""
+description: |-
+ Name of the referent.
+ This field is effectively required, but due to
backwards compatibility is
+ allowed to be empty. Instances of this type with
an empty value here are
+ almost certainly wrong.
+ More info:
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
+type: string
+ optional:
+description: Specify whether the Secret or its key
must
+ be defined
+type: boolean
+required:
+- key
+type: object
+x-kubernetes-map-type: atomic
+ probesRequireAuth:
Review Comment:
Resolved!
##
api/v1beta1/solrcloud_types.go:
##
@@ -1621,6 +1624,15 @@ const (
Basic AuthenticationType = "Basic"
)
+type BootstrapSecurityJson struct {
+ SecurityJsonSecret *corev1.SecretKeySelector
`json:"bootstrapSecurityJson,omitempty"`
+
+ // Flag to indicate if the operator should overwrite an existing
security.json if there are changes
+ // as compared to the underlying secret
+ // +optional
+ Overwrite bool `json:"probesRequireAuth,omitempty"`
Review Comment:
Resolved
--
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-17641: Disable the Security Manager for Java 24+ [solr]
malliaridis commented on code in PR #3153: URL: https://github.com/apache/solr/pull/3153#discussion_r1939602273 ## solr/bin/solr.cmd: ## @@ -94,7 +94,10 @@ IF NOT DEFINED SOLR_SSL_RELOAD_ENABLED ( set "SOLR_SSL_RELOAD_ENABLED=true" ) -REM Enable java security manager by default (limiting filesystem access and other things) +REM Enable java security manager by default for Java 23 and before (limiting filesystem access and other things) +IF !JAVA_MAJOR_VERSION! GEQ "24" ( Review Comment: I've tested again the Windows script changes, seems like the condition is always true, regardless the java version. This should fix the issue: ```suggestion IF !JAVA_MAJOR_VERSION! GEQ 24 ( ``` Note that it matter whether you set `JAVA_HOME` or update the `PATH` variable. -- 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] feat(update-security-json): Update security.json when secret is updated [solr-operator]
mcarroll1 commented on code in PR #744:
URL: https://github.com/apache/solr-operator/pull/744#discussion_r1939611644
##
api/v1beta1/solrcloud_types.go:
##
@@ -1621,6 +1624,15 @@ const (
Basic AuthenticationType = "Basic"
)
+type BootstrapSecurityJson struct {
Review Comment:
Agreed, this is a bit ugly. I'll wait for resolution on the naming change
before changing this
--
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-17648: multiThreaded=true: changed queue implementation [solr]
sigram commented on code in PR #3155:
URL: https://github.com/apache/solr/pull/3155#discussion_r1939248091
##
solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java:
##
@@ -228,25 +229,15 @@ public static ExecutorService
initCollectorExecutor(NodeConfig cfg) {
return null;
}
+// note that Lucene will catch a RejectedExecutionException to just run
the task.
+// Therefore, we shouldn't worry too much about the queue size.
return new MDCAwareThreadPoolExecutor(
indexSearcherExecutorThreads,
indexSearcherExecutorThreads,
0L,
TimeUnit.MILLISECONDS,
-new SynchronousQueue<>(true) { // fairness
- // a hack to force ThreadPoolExecutor to block if threads are busy
- // -- otherwise it will throw RejectedExecutionException;
unacceptable
- @Override
- public boolean offer(Runnable runnable) { // is supposed to not
block, but we do anyway
-try {
- put(runnable); // blocks
-} catch (InterruptedException e) {
- Thread.currentThread().interrupt();
- throw new RuntimeException("interrupted submitting to search
multi-threaded pool", e);
-}
-return true;
- }
-},
+new LinkedBlockingQueue<>(
+EnvUtils.getPropertyAsInteger("solr.searcherCollector.queueSize",
1000)),
Review Comment:
Needs docs?
--
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] in tests replace deprecated IndexSearcher.doc() calls [solr]
cpoerschke commented on code in PR #3149:
URL: https://github.com/apache/solr/pull/3149#discussion_r1939515949
##
solr/core/src/test/org/apache/solr/legacy/TestNumericRangeQuery32.java:
##
@@ -183,12 +183,12 @@ private void testRange(int precisionStep) throws
Exception {
ScoreDoc[] sd = topDocs.scoreDocs;
assertNotNull(sd);
assertEquals("Score doc count" + type, count, sd.length);
- Document doc = searcher.doc(sd[0].doc);
+ Document doc = searcher.storedFields().document(sd[0].doc);
Review Comment:
Here we have an `IndexSearcher` i.e. not a `SolrIndexSearcher` and so not
using `SolrIndexSearcher.getDocFetcher()` here.
--
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] remove deprecated KnnVectorField use [solr]
cpoerschke merged PR #3121: URL: https://github.com/apache/solr/pull/3121 -- 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-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_r1939799714
##
solr/core/src/java/org/apache/solr/handler/admin/CollectionsHandler.java:
##
@@ -975,7 +975,7 @@ public Map execute(
CLUSTERSTATUS,
(req, rsp, h) -> {
new
ClusterStatus(h.coreContainer.getZkController().getZkStateReader(),
req.getParams())
- .getClusterStatus(rsp.getValues());
+ .getClusterStatus(rsp.getValues(),
req.getHttpSolrCall().getUserAgentSolrVersion());
Review Comment:
hmmm; I wonder if HttpSolrCall could be null. No; we don't use
CollectionsHandler in SolrCloud with an EmbeddedSolrServer. I *really* wish
Java had a null-safe navigation operator as used in Kotlin -- `?.`. I suppose
leave this be; not worth adding verbosity for an exotic / hypothetical case.
##
solr/core/src/test/org/apache/solr/cloud/api/collections/TestCollectionAPI.java:
##
@@ -487,7 +489,7 @@ private void clusterStatusWithCollection() throws
IOException, SolrServerExcepti
NamedList rsp = client.request(request);
NamedList cluster = (NamedList) rsp.get("cluster");
assertNotNull("Cluster state should not be null", cluster);
- NamedList collections = (NamedList) cluster.get("collections");
+ Map collections = (Map) cluster.get("collections");
Review Comment:
very minor: consider use of `var` in any place where we cast so we don't
repeat the type. But again this is minor; feel free to just let this be and
consider this advice to future changes.
##
solr/solrj/src/test/org/apache/solr/client/solrj/impl/ClusterStateProviderTest.java:
##
Review Comment:
I appreciate your thoroughness. I should merge this as-is.
But...
In an ideal world, you wouldn't have had any need to do this -- no time
spent for you or an explicit test here to maintain in perpetuity. Solr is
lacking backwards-compatibility test infrastructure. A hello-world SolrCloud
would have caught this problem. Such a thing would nowadays almost certainly
use Docker (to run old Solr versions) and use `TestContainers` in Java to
arrange for that. We do this at work, albeit not for backwards-compatibility
but more for realistic / production like testing. The comment thread in
https://issues.apache.org/jira/browse/SOLR-14903 gets at this. I should create
a JIRA issue to spell out this need more. Really should be on our roadmap.
I'll do that too.
--
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-17648: multiThreaded=true: changed queue implementation [solr]
dsmiley commented on code in PR #3155:
URL: https://github.com/apache/solr/pull/3155#discussion_r1939755482
##
solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java:
##
@@ -228,25 +229,15 @@ public static ExecutorService
initCollectorExecutor(NodeConfig cfg) {
return null;
}
+// note that Lucene will catch a RejectedExecutionException to just run
the task.
+// Therefore, we shouldn't worry too much about the queue size.
return new MDCAwareThreadPoolExecutor(
indexSearcherExecutorThreads,
indexSearcherExecutorThreads,
0L,
TimeUnit.MILLISECONDS,
-new SynchronousQueue<>(true) { // fairness
- // a hack to force ThreadPoolExecutor to block if threads are busy
- // -- otherwise it will throw RejectedExecutionException;
unacceptable
- @Override
- public boolean offer(Runnable runnable) { // is supposed to not
block, but we do anyway
-try {
- put(runnable); // blocks
-} catch (InterruptedException e) {
- Thread.currentThread().interrupt();
- throw new RuntimeException("interrupted submitting to search
multi-threaded pool", e);
-}
-return true;
- }
-},
+new LinkedBlockingQueue<>(
+EnvUtils.getPropertyAsInteger("solr.searcherCollector.queueSize",
1000)),
Review Comment:
IMO we don't need to document _obscure_ settings (I think this is). If you
think it should be documented, let me know where it should be. If this queue
size is exceeded, the outcome is still a working system but the performance
will be somewhat less than what it otherwise would be. FWIW 1000 feels about
right to me. I reviewed the code in Lucene 9.12 that cleverly uses the parent
thread.
I plan to change this property to be "solr.search.multiThreaded.queueSize"
so as to have a category after solr. -- see
https://cwiki.apache.org/confluence/display/SOLR/System+property+naming+structure
--
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] [Created] (SOLR-17649) Multivalue facets on enum field type returns empty result when using JsonFacet
Thomas Wöckinger created SOLR-17649:
---
Summary: 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.8, 9.6.1, 9.7, 9.6, 9.4.1, 9.5, 9.4
Reporter: Thomas Wöckinger
When using JsonFacet api on a multivalued EnumFieldType with facet method
'enum' the
{color:#232629}{color:#00}FacetFieldProcessorByArrayDV{color}{color} will
be used.
At line 96 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
{color:#232629}{color:#00}FacetFieldProcessorByArrayDV{color}{color} facet
processor for collecting facets.
--
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-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
]
Thomas Wöckinger updated SOLR-17649:
Description:
When using JsonFacet api on a multivalued EnumFieldType with facet method
'enum' the {color:#232629}FacetFieldProcessorByArrayDV{color} will be used.
At line 96 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.
was:
When using JsonFacet api on a multivalued EnumFieldType with facet method
'enum' the {color:#232629}FacetFieldProcessorByArrayDV{color} will be used.
At line 96 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, these feature was working on the 8.x
releases.
> 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
>
> When using JsonFacet api on a multivalued EnumFieldType with facet method
> 'enum' the {color:#232629}FacetFieldProcessorByArrayDV{color} will be used.
> At line 96 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.
--
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-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
]
Thomas Wöckinger updated SOLR-17649:
Description:
When using JsonFacet api on a multivalued EnumFieldType with facet method
'enum' the {color:#232629}FacetFieldProcessorByArrayDV{color} will be used.
At line 96 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, these feature was working on the 8.x
releases.
was:
When using JsonFacet api on a multivalued EnumFieldType with facet method
'enum' the
{color:#232629}{color:#00}FacetFieldProcessorByArrayDV{color}{color} will
be used.
At line 96 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
{color:#232629}{color:#00}FacetFieldProcessorByArrayDV{color}{color} facet
processor for collecting facets.
> 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
>
> When using JsonFacet api on a multivalued EnumFieldType with facet method
> 'enum' the {color:#232629}FacetFieldProcessorByArrayDV{color} will be used.
> At line 96 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, these feature was working on the 8.x
> releases.
--
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-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
]
Thomas Wöckinger updated SOLR-17649:
Description:
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.
was:
When using JsonFacet api on a multivalued EnumFieldType with facet method
'enum' the {color:#232629}FacetFieldProcessorByArrayDV{color} will be used.
At line 96 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 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
>
> 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-17582: Stream CLUSTERSTATUS API for SolrJ version >= 9.9 [solr]
mlbiscoc commented on PR #3156: URL: https://github.com/apache/solr/pull/3156#issuecomment-2631588200 Meant to put into draft. A few more things I need to add. -- 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
