[PR] SOLR-17454: Remove debugging error message [solr]
ahankinson opened a new pull request, #2720: URL: https://github.com/apache/solr/pull/2720 https://issues.apache.org/jira/browse/SOLR-17454 # Description This PR removes an errant ERROR message in the Solr logs. # Solution This message is not an error, and since there are no other logging calls in this file, it was simply removed. # Checklist Please review the following and check all that apply: - [x] 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. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] 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-17454) ERROR message in logs with multithreaded searches
[
https://issues.apache.org/jira/browse/SOLR-17454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17454:
--
Labels: docs error log-level multithreaded pull-request-available (was:
docs error log-level multithreaded)
> ERROR message in logs with multithreaded searches
> -
>
> Key: SOLR-17454
> URL: https://issues.apache.org/jira/browse/SOLR-17454
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Affects Versions: 9.7
> Environment: Solr 9.7.0
> Ubuntu 22.04 LTS
>Reporter: Andrew Hankinson
>Priority: Minor
> Labels: docs, error, log-level, multithreaded,
> pull-request-available
> Fix For: 9.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent a message to the Users mailing list about this, but received no
> response. However, I think it is still a problem.
> When searching with 9.7.0 and enabled multithreaded search, I now get an
> ERROR message in my logs:
> {code:java}
> 2024-09-16 08:32:05.795 ERROR (qtp1756573246-34-null-1) [c: s: r: x:core_name
> t:null-1] o.a.s.s.MultiThreadedSearcher raw read max=5922019 {code}
> The max number is the total number of documents in the core.
> I've tracked it down to this part of the code:
> [https://github.com/apache/solr/blob/5bc7c1618e05b35bd0fa8471ae09329357a82036/solr/core/src/java/org/apache/solr/search/MultiThreadedSearcher.java#L86-L91]
> I'm not entirely convinced that an ERROR level message is necessary here?
> * The query seems to still function;
> * Once the error condition is logged, the code seems to create a new doc set
> and continues;
> * The documentation doesn't suggest anything for how to avoid this? I'm not
> sure why "needDocSet" is true here, and how it can be anything otherwise?
> Surely an "info" or "warn" log message is more appropriate for these cases?
> Unless it really is an error condition, but then the docs should be updated
> to mention what could be done to avoid the error?
--
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: [I] Add support to set capabilities on Solr cloud container's security context [solr-operator]
bcbrockway commented on issue #489: URL: https://github.com/apache/solr-operator/issues/489#issuecomment-2368300581 To the maintainers: Is there a particular reason you specify your own fields in podOptions.podSecurityContext instead of just accepting a [k8s podSecurityContext API type](https://pkg.go.dev/k8s.io/api/core/v1#PodSecurityContext)? Using the upstream k8s type would mean that no-one would manually have to add fields available in the k8s type to the securityContext objects in this CRD, right? I'm definitely no expert, but I've seen this done in other operators. -- 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] HttpShardHandler: Fix extension hook transformResponse [solr]
fsparv commented on PR #2661: URL: https://github.com/apache/solr/pull/2661#issuecomment-2368855403 If users have implemented a custom handler (as is clearly implied via the doc on the method, and it's no-op default implementation) their code would need to be updated and rebuilt. Seems like something someone assessing an upgrade effort would want to know about...? -- 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-17442) CLI: Resolve -v flag conflict (version, value, verbose)
[ https://issues.apache.org/jira/browse/SOLR-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17442: -- Labels: cli pull-request-available (was: cli) > CLI: Resolve -v flag conflict (version, value, verbose) > --- > > Key: SOLR-17442 > URL: https://issues.apache.org/jira/browse/SOLR-17442 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: cli, SolrCLI >Affects Versions: main (10.0), 9.6, 9.7, 9.6.1 >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Minor > Labels: cli, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The CLI code currently uses the -v flag for "version", "value" and "verbose". > Since -v is commonly used for printing the current version, it should take > precedence over the other options. > In order to resolve this conflict and to avoid future confussion, we should > deprecate (9x) and remove (10.0) the option "verbose" > (-v/-V/-verbose/--verbose), introduce "debug" (-d/–debug) in place of > "verbose" and deprecate (9x) and remove (10.0) the usage of -v for "value". > Note that the option of uppercase -V was only partly replaced in previous PRs > and should completely be merged and deprecated/removed together with -v > according to the above proposal, to avoid further confussion. > Use the [Solr Arguments - Migration > Overview|https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing] > for a better overview of the current state. -- 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-17442: Resolve -v flag conflict (version, value, verbose) [solr]
epugh opened a new pull request, #2721: URL: https://github.com/apache/solr/pull/2721 https://issues.apache.org/jira/browse/SOLR-17442 # Description Deprecating -v in favour of -d. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # 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
Re: [PR] HttpShardHandler: Fix extension hook transformResponse [solr]
dsmiley commented on PR #2661: URL: https://github.com/apache/solr/pull/2661#issuecomment-2368533696 Renaming a protected method doesn't deserve a JIRA and wasting readers time to read about it in CHANGES.txt. -- 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] [Regression] security.json is not uploaded during the first initialization of SolrCloud [solr-operator]
MitchIonascu commented on issue #720: URL: https://github.com/apache/solr-operator/issues/720#issuecomment-2368584644 Hi there! We get the same issue when initializing a new solr cloud cluster with version 9.7.0.  Solr is then exposed to the internet but with no basic authentication(or any authentication), consistent with security.json not being loaded at all. We can bypass this by restarting solr immediately after the initialization, but it would be nice to get a fix for this. Thank you! -- 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-17378: Add a RequestHandler metric for "number of outstanding concurrent requests" [solr]
github-actions[bot] commented on PR #2591: URL: https://github.com/apache/solr/pull/2591#issuecomment-2369805690 This PR has had no activity for 60 days and is now labeled as stale. Any new activity or converting it to draft will remove the stale label. To attract more reviewers, please tag people who might be familiar with the code area and/or notify the d...@solr.apache.org mailing list. Thank you for your contribution! -- 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] HttpShardHandler: Fix extension hook transformResponse [solr]
dsmiley commented on PR #2661: URL: https://github.com/apache/solr/pull/2661#issuecomment-2369101061 it's about a trivial change as changes go. Users (and I count myself as impacted at work BTW) would find out upon upgrading. Tons of other changes happen without CHANGES.txt prescribing every little detail as the name of a method. -- 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-17285: Move RemoteSolrException to SolrClient in v10 [solr]
dsmiley commented on PR #2587: URL: https://github.com/apache/solr/pull/2587#issuecomment-2369965706 @samuelrivascoding how shall I credit you (name you) in CHANGES.txt? If I don't hear back, it'll be literally _that_. -- 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-5951) SolrDispatchFilter no longer displays useful error message on statup when logging jars are missing
[
https://issues.apache.org/jira/browse/SOLR-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884083#comment-17884083
]
David Smiley commented on SOLR-5951:
[~uschindler] , I think the problem of not having the right logging JARs should
be a non-issue since Solr 5, where Solr insists on Jetty pre-packaged with our
opinionated choice of logging JARs. If someone messes with them; they are on
their own to figure out the right ones. I'm skeptical a person would really
need the code change here to figure that out. I'd like to remove
CheckLoggingConfiguration and BaseSolrFilter and BaseSolrServlet, which are in
servitude of it. WDYT? My motivation is merely a small simplification.
> SolrDispatchFilter no longer displays useful error message on statup when
> logging jars are missing
> --
>
> Key: SOLR-5951
> URL: https://issues.apache.org/jira/browse/SOLR-5951
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.7, 4.7.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 4.7.2, 4.8, 6.0
>
> Attachments: SOLR-5951.patch
>
>
> We no longer have logging jars in the webapp since SOLR-3706. Because of this
> we added a extra check in SolrDispatchFilter's ctor to print a nice exception
> if the logging jars were failing. This check was unfortunately never tests
> and recently broke:
> The check delays initialization of the Logger instance to inside a try-catch
> block inside the explicit ctor. If it fails with ClassNotFound, it throws
> Exception.
> Recently we upgraded to a newer HttpClient version. Unfortunately
> SolrDispatchFliter also has an implicit constructor a few lines before the
> main constructor:
> {code:java}
> protected final HttpClient httpClient = HttpClientUtil.createClient(new
> ModifiableSolrParams()); // <-- this breaks the detection
>
> private static final Charset UTF8 = StandardCharsets.UTF_8;
> public SolrDispatchFilter() {
> try {
> log = LoggerFactory.getLogger(SolrDispatchFilter.class);
> } catch (NoClassDefFoundError e) {
> throw new SolrException(
> ErrorCode.SERVER_ERROR,
> "Could not find necessary SLF4j logging jars. If using Jetty, the
> SLF4j logging jars need to go in "
> +"the jetty lib/ext directory. For other containers, the
> corresponding directory should be used. "
> +"For more information, see:
> http://wiki.apache.org/solr/SolrLogging";,
> e);
> }
> }
> {code}
> The first line above {{HttpClientUtil.createClient(new
> ModifiableSolrParams());}} breaks the whole thing, because it is executed
> before the declared constructor. The user just sees a ClassNotFoundEx at this
> line of code, the nice error message is hidden.
> Because this is so easy to break, we should make the whole thing more safe
> (any maybe test it). 2 options:
> # Into the webapp add a fake Servlet (not bound to anything, just loaded
> first) that does not use any Solr classes at all, nothing only plain java
> # Alternatively add a Superclass between ServletFilter and SolrDispatchFilter
> (pkg-private). When the servlet container loads SolrDispatchFilter, it has in
> any case to first load the superclass. And this superclass does the check and
> throws ServletException or whatever (no Solr Exception) with the message from
> the current code.
> I tend to the second approach, because it does not need to modify web-inf. It
> will also work with other Solr servlets, they must just extend this hidden
> class. I will provide a patch for that.
--
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
