Re: [PR] SOLR-17607: Http ClusterStateProvider, lazy connect [solr]
dsmiley commented on code in PR #3249:
URL: https://github.com/apache/solr/pull/3249#discussion_r1986372473
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseHttpClusterStateProvider.java:
##
@@ -78,28 +78,12 @@ public void init(List solrUrls) throws Exception {
}
})
.collect(Collectors.toList());
+this.urlScheme = this.configuredNodes.get(0).getProtocol();
Review Comment:
In my latest commit, I ended up populating urlScheme whenever we
successfully fetch liveNodes. I think it's more elegant and allows someone to
specify URLs that only vary by scheme (http vs https) which actually sounds
very useful. Hope you like it.
--
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-17607: Http ClusterStateProvider, lazy connect [solr]
dsmiley commented on code in PR #3249:
URL: https://github.com/apache/solr/pull/3249#discussion_r1986353034
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseHttpClusterStateProvider.java:
##
@@ -78,28 +78,12 @@ public void init(List solrUrls) throws Exception {
}
})
.collect(Collectors.toList());
+this.urlScheme = this.configuredNodes.get(0).getProtocol();
Review Comment:
I agree that the URL scheme shouldn't vary across the URLs given; that
should be erroneous. An exception would be nice.
--
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-17607: Http ClusterStateProvider, lazy connect [solr]
dsmiley commented on code in PR #3249:
URL: https://github.com/apache/solr/pull/3249#discussion_r1986363412
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseHttpClusterStateProvider.java:
##
@@ -230,43 +214,41 @@ private SimpleOrderedMap submitClusterStateRequest(
}
@Override
- public Set getLiveNodes() {
+ public synchronized Set getLiveNodes() {
+// synchronized because there's no value in multiple doing this at the
same time
if (TimeUnit.SECONDS.convert((System.nanoTime() - liveNodesTimestamp),
TimeUnit.NANOSECONDS)
-> getCacheTimeout()) {
+<= getCacheTimeout()) {
+ return this.liveNodes; // cached copy is fresh enough
+}
+if (liveNodes != null) { // thus we've fetched liveNodes previously
Review Comment:
I don't follow. `liveNodes != null` is only false in the initial state.
assuming getLiveNodes is successful, liveNodes will never be null again.
--
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-17607: Http ClusterStateProvider, lazy connect [solr]
mlbiscoc commented on code in PR #3249:
URL: https://github.com/apache/solr/pull/3249#discussion_r1986281671
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseHttpClusterStateProvider.java:
##
@@ -230,43 +214,41 @@ private SimpleOrderedMap submitClusterStateRequest(
}
@Override
- public Set getLiveNodes() {
+ public synchronized Set getLiveNodes() {
+// synchronized because there's no value in multiple doing this at the
same time
if (TimeUnit.SECONDS.convert((System.nanoTime() - liveNodesTimestamp),
TimeUnit.NANOSECONDS)
-> getCacheTimeout()) {
+<= getCacheTimeout()) {
+ return this.liveNodes; // cached copy is fresh enough
+}
+if (liveNodes != null) { // thus we've fetched liveNodes previously
Review Comment:
Doesn't adding this mean we never update the node list after the first
`connect` using the existing liveNodes attribute? (assuming liveNodes populates
successfully upon connection to Solr). Now it will only ever update the node
list by fetching from configured nodes.
What if the only liveNode is a node not in the configured list and the cache
timeout hit, then the node would never be fetched from because it isn't the in
configured list.
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseHttpClusterStateProvider.java:
##
@@ -78,28 +78,12 @@ public void init(List solrUrls) throws Exception {
}
})
.collect(Collectors.toList());
+this.urlScheme = this.configuredNodes.get(0).getProtocol();
Review Comment:
Looking at this now and just noticing, this seems a bit awkward. The
`urlScheme` is set based on the first url in the list for http/https but before
it was the last. But what if there is a mix of http/https? Not sure if it was
intentional. It seems there shouldn't be a case where there is a mix of
http/https urls in the configured list but depending on the ordering now, some
urls may or may not work with `Utils.getBaseUrlForNodeName` when getting the
live nodes list.
What do you think of throwing an exception if the urls are mixed with
http/https and enforce a single protocol?
--
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] [Assigned] (SOLR-17658) Implement Admin UI Start Screen
[ https://issues.apache.org/jira/browse/SOLR-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christos Malliaridis reassigned SOLR-17658: --- Assignee: Christos Malliaridis > Implement Admin UI Start Screen > --- > > Key: SOLR-17658 > URL: https://issues.apache.org/jira/browse/SOLR-17658 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Christos Malliaridis >Assignee: Christos Malliaridis >Priority: Major > Labels: new-ui, newdev, ui > > The new UI is built for web (shipped with Solr server and webapp) and desktop > (JVM). The POC has a hardcoded URL to localhost:8983 to interact with the > API. In order to have an option to allow the user to select the Solr instance > (URL), a start screen was designed that should be displayed as initial screen > / entrypoint. > h2. Task > Implement the start screen according to the [new > designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1185-13443&t=vMgOa9QlzQZSdjLf-1]. > Only the first form where the user can provide a Solr URL is relevant for > this ticket. > h2. Acceptance Criteria > - When the user opens for the first time the new UI, the start screen is > displayed > - On desktop, the user can edit the Solr URL and provide a custom URL > - A placeholder to http://localhost:8983 is used on desktop as default value > for the Solr URL > - If the user is on web and accessed the Solr instance via a Solr URL, the > host from the current URL is used and the user is automatically connected > - When successfully connected, the user is redirected to the Dashboard (or > any existing screen for now) > - The provided Solr URL is used in the HTTP client > - The logout button redirects the user back to the start screen > - A warning dialog is shown before connecting to an HTTP URL (see designs) > h2. Additional Information > You should avoid handling authentication / authorization in this issue, as > this is addressed in a separate issue. The designs cover an authentication > form, but that can be ignored for now. -- 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-17607) HTTP ClusterStateProvider should defer talking to Solr until first use
[ https://issues.apache.org/jira/browse/SOLR-17607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933665#comment-17933665 ] David Smiley commented on SOLR-17607: - With my PR; there is no retry-timeout. ZkClientClusterStateProvider has none either. But the situation of concern isn't permanent... if another request comes later once Solr is up, it will succeed at that time. > HTTP ClusterStateProvider should defer talking to Solr until first use > -- > > Key: SOLR-17607 > URL: https://issues.apache.org/jira/browse/SOLR-17607 > Project: Solr > Issue Type: Improvement > Components: SolrCloud, SolrJ >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > When using CloudSolrClient with HTTP URLs to get the ClusterState (HTTP > ClusterStateProvider), it will talk to Solr when the client is created to > fetch the live nodes. But maybe Solr isn't available at this time; it's > annoying to require that Solr is available at the time that the > CloudSolrClient is constructed. The ZK one is deferred till first use; I > propose the same behavior for HTTP. -- 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-17599: CrossDC should not use the MirroringUpdateHandler when replaying updates from the transaction log or when doing PeerSync. [solr]
github-actions[bot] commented on PR #2975: URL: https://github.com/apache/solr/pull/2975#issuecomment-2709144186 This PR has had no activity for 60 days and is now labeled as stale. Any new activity 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. To exempt this PR from being marked as stale, make it a draft PR or add the label "exempt-stale". If left unattended, this PR will be closed after another 60 days of inactivity. 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
[jira] [Commented] (SOLR-17693) Upgrade to Apache Curator 5.8.0
[ https://issues.apache.org/jira/browse/SOLR-17693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933694#comment-17933694 ] ASF subversion and git services commented on SOLR-17693: Commit 89ad80e423e19ea3cf317e439499400d0d860d78 in solr's branch refs/heads/deprecations from Solr Bot [ https://gitbox.apache.org/repos/asf?p=solr.git;h=89ad80e423e ] SOLR-17693: Update apache.curator to v5.8.0 (#3245) > Upgrade to Apache Curator 5.8.0 > --- > > Key: SOLR-17693 > URL: https://issues.apache.org/jira/browse/SOLR-17693 > Project: Solr > Issue Type: Sub-task >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Labels: pull-request-available > Fix For: main (10.0) > > Time Spent: 10m > Remaining Estimate: 0h > > This Curator release includes the necessary things to be able to use Curator > Recipes in Apache Solr. -- 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-16903) Use Path instead of File in Java Code
[ https://issues.apache.org/jira/browse/SOLR-16903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933683#comment-17933683 ] ASF subversion and git services commented on SOLR-16903: Commit 53fe9cddc7b309f03ba92926bc02e6af100cdf1a in solr's branch refs/heads/deprecations from Andrey Bozhko [ https://gitbox.apache.org/repos/asf?p=solr.git;h=53fe9cddc7b ] SOLR-16903: Switch CoreContainer.getSolrHome to return Path instead of String (#3204) > Use Path instead of File in Java Code > - > > Key: SOLR-16903 > URL: https://issues.apache.org/jira/browse/SOLR-16903 > Project: Solr > Issue Type: Improvement >Affects Versions: 9.3 >Reporter: Eric Pugh >Priority: Minor > Labels: newdev, pull-request-available > Fix For: main (10.0) > > Time Spent: 6h 10m > Remaining Estimate: 0h > > As a community, we have decided to migrate to using java.nio.file.Path in > place of java.io.File in our codebase. > This ticket is to go through the codebase and make that change. We'd also > like to add the java.io.File pattern to our forbidden-apis setup. -- 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-16391) Cosmetic improvements and migration to JAX-RS (collection, collection prop, core CRUD APIs)
[
https://issues.apache.org/jira/browse/SOLR-16391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933679#comment-17933679
]
ASF subversion and git services commented on SOLR-16391:
Commit 5fafabdb13d62b2d590f7602b7720042e5f3a3db in solr's branch
refs/heads/deprecations from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=5fafabdb13d ]
SOLR-16391: Convert create-core, core-status to JAX-RS (#3054)
The migration to JAX-RS implicitly adds these APIs to the OAS, and ensures
autogeneration of SolrRequest/SolrResponse types.
> Cosmetic improvements and migration to JAX-RS (collection, collection prop,
> core CRUD APIs)
> ---
>
> Key: SOLR-16391
> URL: https://issues.apache.org/jira/browse/SOLR-16391
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
>Affects Versions: main (10.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Labels: newdev, pull-request-available
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> As mentioned on SOLR-15781, the v2 API currently has an experimental
> designation, and the community has expressed an interest in using this period
> to update our v2 endpoints to be more REST-ful and consistent. The current
> plan is to follow the specific changes laid out in [this
> spreadsheet|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing],
> though of course nothing there is set in stone and there are still warts to
> be worked out.
> While we're touching the code for these endpoints, we should also convert
> them to JAX-RS framework definitions. (This was initially tracked as a
> separate effort - see SOLR-16370 - but the edit that were required ended up
> overlapping so significantly with the "cosmetic" improvements here that in
> practice it almost always makes sense to do the two together.)
> This ticket plans to tackle making the changes required for Solr's collection
> and collection-prop CRUD APIs, as well as its collection-status APIs. These
> are described in detail in the spreadsheet linked above, but are summarized
> in the tables below for convenience and ease of tracking progress.
> *JAX-RS Conversion and Cosmetic Changes*
> ||API Name||Original Form||Desired Form||Status||Volunteer||
> |-Create Collection-|-POST /api/collections \{create: \{...\}\}-|-POST
> /api/collections \{...\}-|-Finished-|-Jason-|
> |-Get Collection Details-|-N/A-|-GET
> /api/collections/collName?details=specificFlags-|-Finished-|-Jason-|
> |Create Core|POST /api/cores \{"create": \{...\}\}|POST /api/cores
> \{...\}|Open|N/A|
> |Collection Ping/Healthcheck|GET /api/collections/collName/admin/ping|GET
> /api/collections/collName/health|Open|N/A|
> |Is Collection Healthcheck Enabled|GET
> /api/collections/collName/admin/ping?action=STATUS|GET
> /api/collections/collName/health/status|Open|N/A|
> |Enable/Disable Collection Healthcheck|GET
> /api/collections/collName/admin/ping?action=enable\|disable|PUT
> /api/collections/collName/health/status \{"enabled": true\|false\}|Open|N/A|
> |-Delete Collections-|-DELETE /api/collections/collName-|-DELETE
> /api/collections/collName-|-Finished-|-Jason-|
> |-Set Collection Property-|-POST /api/collections/collName
> \{set-collection-property: \{...\}\}-|-PUT
> /api/collections/collName/properties/propName \{"value":
> "someVal"\}-|-Finished-|-Jason-|
> |-Delete Collection Property-|-POST /api/collections/collName
> \{set-collection-property: \{...\}\}-|-DELETE
> /api/collections/collName/properties/propName-|-Finished-|-Jason-|
> *JAX-RS Conversion Only*
> ||API Name||Endpoint||Status||Volunteer||
> |-List Collections-|-GET /api/collections-|-Finished-|-Jason-|
> Some helpful links related to these changes these changes. Should help get
> any interested newcomers started!
> * For detailed information on Solr's current and desired v2 APIs see the
> spreadsheet
> [here|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing]
> * [Discussion of how APIs work in Solr
> (video)|https://www.youtube.com/watch?v=iIpvfXBjDog]
> * [Step-by-step guide to creating
> APIs|https://issues.apache.org/jira/browse/SOLR-15737?focusedCommentId=17617923&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17617923]
> using the JAX-RS v2 API framework
> * [Example PR for a similar change|https://github.com/apache/solr/pull/1679]
--
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-17518) Refactor out a XmlRequestWriter so that RequestWriter is abstract
[ https://issues.apache.org/jira/browse/SOLR-17518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933688#comment-17933688 ] ASF subversion and git services commented on SOLR-17518: Commit 085bfc61e36cf8945107e96c6e750bb966786b6f in solr's branch refs/heads/deprecations from Pierre Salagnac [ https://gitbox.apache.org/repos/asf?p=solr.git;h=085bfc61e36 ] SOLR-17518: Remove deprecated XML methods from UpdateRequest (#3215) > Refactor out a XmlRequestWriter so that RequestWriter is abstract > - > > Key: SOLR-17518 > URL: https://issues.apache.org/jira/browse/SOLR-17518 > Project: Solr > Issue Type: Task > Components: SolrJ >Reporter: David Smiley >Assignee: Pierre Salagnac >Priority: Minor > Labels: newdev, pull-request-available > Fix For: main (10.0) > > Time Spent: 2h 20m > Remaining Estimate: 0h > > RequestWriter writes XML; some subclasses write other things. This is > terrible API design; the XML choice should be a subclass, RequestWriter > should be abstract (or an interface). > While we're at this, the XML generation is kind of split into multiple > places; it should be consolidated: UpdateRequest & ClientUtils have XML > generation methods. Those methods should move to the new XmlRequestWriter. > BinaryRequestWriter should probably be final and/or ensure the CBOR one does > not subclass it, which is weird since CBOR != "javabin". > Be sure to note this refactoring in the update notes since SolrJ users will > be impacted. -- 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-17677) {!join} in delete-by-query throws ClassCastException and closes IndexWriter
[
https://issues.apache.org/jira/browse/SOLR-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933682#comment-17933682
]
ASF subversion and git services commented on SOLR-17677:
Commit 3a492203cf4d9b7ed9431de9378049992f7da355 in solr's branch
refs/heads/deprecations from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=3a492203cf4 ]
SOLR-17677: HashRangeQuery doesn't NEED SolrIndexSearcher (#3206)
> {!join} in delete-by-query throws ClassCastException and closes IndexWriter
> ---
>
> Key: SOLR-17677
> URL: https://issues.apache.org/jira/browse/SOLR-17677
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 9.8
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Labels: pull-request-available
> Fix For: main (10.0), 9.9, 9.8.1
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Solr's JoinQuery implementation explicitly casts the provided "IndexSearcher"
> to a "SolrIndexSearcher". In most contexts this assumption bears out, but
> not always.
> One counter-example is Solr's "Delete By Query" codepath, which runs the
> deletion query using a "raw" Lucene IndexSearcher. (Presumably this is
> because the new searcher has just been opened?). Any DBQ containing a join
> query will throw a ClassCastException, which then bubbles up to the
> IndexWriter as a "tragic" Lucene exception, force-closing the IndexWriter and
> throwing the surrounding SolrCore in to a bad state:
> {code}
> 2025-02-18 19:39:25.339 ERROR (qtp1426725223-177-localhost-73)
> [c:techproducts s:shard2 r:core_node3 x:techproducts_shard2_replica_n1
> t:localhost-73] o.a.s.h.RequestHandlerBase Server exception =>
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.normalizeReceivedException(RequestHandlerBase.java:272)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:238)
> ~[?:?]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> at
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
> ~[?:?]
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:241)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilterRetry$0(SolrDispatchFilter.java:198)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:227)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:197)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilterRetry(SolrDispatchFilter.java:192)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
> ~[?:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:97)
> ~[jetty-servlet-api-4.0.6.jar:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)
> ~[jetty-security-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1580)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1384)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.
[jira] [Commented] (SOLR-17656) Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING
[ https://issues.apache.org/jira/browse/SOLR-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933695#comment-17933695 ] ASF subversion and git services commented on SOLR-17656: Commit b81dc4b5f29441806235a51ee87970a93bddeac5 in solr's branch refs/heads/deprecations from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=b81dc4b5f29 ] SOLR-17656: Fix TestPullReplica.testRealTimeGet() > Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING > --- > > Key: SOLR-17656 > URL: https://issues.apache.org/jira/browse/SOLR-17656 > Project: Solr > Issue Type: New Feature >Reporter: Chris M. Hostetter >Assignee: Chris M. Hostetter >Priority: Major > Fix For: main (10.0), 9.9 > > Attachments: SOLR-17656-1.patch, SOLR-17656.patch > > > In situations where a Solr cluster undergoes a rolling restart (or some other > "catastrophic" failure situations requiring/causing solr node restarts) there > can be a snowball effect of poor performance (or even solr node crashing) due > to fewer then normal replicas serving query requests while replicas on > restarting nodes are DOWN or RECOVERING – especially if shard leaders are > also affected, and (restarting) replicas first must wait for a leader > election before they can recover (or wait to finish recovery from an > over-worked leader). > For NRT type usecases, RECOVERING is really a necessary evil to ensure every > replicas is up to date before handling NRT requests – but in the case of PULL > replicas, which are expected to routinely "lag" behind their leader, I've > talked to a lot of Solr users w/usecases where they would be happy to have > PULL replicas back online serving "stale" data ASAP, and let normal > IndexFetching "catchup" with the leader later. > I propose we support a new "advanced" replica property that can be set on > PULL replicas by expert level users, to indicate: on (re)init, these replicas > may skip RECOVERING and go directly to ACTIVE. -- 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-17677) {!join} in delete-by-query throws ClassCastException and closes IndexWriter
[
https://issues.apache.org/jira/browse/SOLR-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933680#comment-17933680
]
ASF subversion and git services commented on SOLR-17677:
Commit 76e9b331a35ae2a80a675c98794b677758470b09 in solr's branch
refs/heads/deprecations from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=76e9b331a35 ]
SOLR-17677: Ensure DBQ is safe before running (#3203)
Portions of the DBQ codepath execute the deletion query with a standard
Lucene IndexSearcher, which upsets some Solr Query implementations that
have been built to assume SolrIndexSearcher in (e.g.)
Query.createWeight.
This commit adds checks for this case, which work by using a Lucene
"QueryVisitor" to iterate over a parsed query tree and detect whether
any of the individual queries require SolrIndexSearcher.
(The QueryVisitor implementation has been added as 'lucene.
experimental', to leave us free to modify or remove it in future as desired.)
> {!join} in delete-by-query throws ClassCastException and closes IndexWriter
> ---
>
> Key: SOLR-17677
> URL: https://issues.apache.org/jira/browse/SOLR-17677
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 9.8
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Labels: pull-request-available
> Fix For: main (10.0), 9.9, 9.8.1
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Solr's JoinQuery implementation explicitly casts the provided "IndexSearcher"
> to a "SolrIndexSearcher". In most contexts this assumption bears out, but
> not always.
> One counter-example is Solr's "Delete By Query" codepath, which runs the
> deletion query using a "raw" Lucene IndexSearcher. (Presumably this is
> because the new searcher has just been opened?). Any DBQ containing a join
> query will throw a ClassCastException, which then bubbles up to the
> IndexWriter as a "tragic" Lucene exception, force-closing the IndexWriter and
> throwing the surrounding SolrCore in to a bad state:
> {code}
> 2025-02-18 19:39:25.339 ERROR (qtp1426725223-177-localhost-73)
> [c:techproducts s:shard2 r:core_node3 x:techproducts_shard2_replica_n1
> t:localhost-73] o.a.s.h.RequestHandlerBase Server exception =>
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.normalizeReceivedException(RequestHandlerBase.java:272)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:238)
> ~[?:?]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> at
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
> ~[?:?]
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:241)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilterRetry$0(SolrDispatchFilter.java:198)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:227)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:197)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilterRetry(SolrDispatchFilter.java:192)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
> ~[?:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:97)
> ~[jetty-servlet-api-4.0.6.jar:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)
> ~[jetty-security-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.s
[jira] [Commented] (SOLR-17669) SolrJ getBeans Field with wildcard: reduce memory
[ https://issues.apache.org/jira/browse/SOLR-17669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933687#comment-17933687 ] ASF subversion and git services commented on SOLR-17669: Commit 5ddaf5f9d95f86913c6fe0924cd5d9b13fdb456c in solr's branch refs/heads/deprecations from Martin Anzinger [ https://gitbox.apache.org/repos/asf?p=solr.git;h=5ddaf5f9d95 ] SOLR-17669: SolrJ getBeans: reduce memory for dynamic/wildcard Field annotated methods (#3179) Reduce memory Consumption by 80-90% as found by one user. Might increase matching performance as well. > SolrJ getBeans Field with wildcard: reduce memory > - > > Key: SOLR-17669 > URL: https://issues.apache.org/jira/browse/SOLR-17669 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Affects Versions: 9.8 >Reporter: Peter Kroiss >Priority: Major > Labels: pull-request-available > Fix For: 9.9 > > Attachments: Screenshot 2025-02-11 at 11.00.15.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Replace the Pattern.matcher for DynamicFields with standard String Operations. > In our Environment that fix reduced the Memory Overhead when mapping the > Objects by 80-90% (see Screenshot) > Pull Request will be opened created by us. Would be great to fix in Solr 9.8.1 > -- 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=17933686#comment-17933686 ] ASF subversion and git services commented on SOLR-17650: Commit 0a50edab23350947157731ab973a1f07ec7cf69a in solr's branch refs/heads/deprecations from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=0a50edab233 ] SOLR-17650: Fix tests for unordered buffered updates (#3197) > 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 >Assignee: Houston Putman >Priority: Major > Labels: pull-request-available > Fix For: 9.9 > > Time Spent: 1h > Remaining Estimate: 0h > > 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-17518) Refactor out a XmlRequestWriter so that RequestWriter is abstract
[ https://issues.apache.org/jira/browse/SOLR-17518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933684#comment-17933684 ] ASF subversion and git services commented on SOLR-17518: Commit aa6b3761f8475a7a5f14d807fad91068678131f2 in solr's branch refs/heads/deprecations from Pierre Salagnac [ https://gitbox.apache.org/repos/asf?p=solr.git;h=aa6b3761f84 ] SOLR-17518: Deprecate UpdateRequest.getXml() and replace it with XMLRequestWriter (#3200) > Refactor out a XmlRequestWriter so that RequestWriter is abstract > - > > Key: SOLR-17518 > URL: https://issues.apache.org/jira/browse/SOLR-17518 > Project: Solr > Issue Type: Task > Components: SolrJ >Reporter: David Smiley >Assignee: Pierre Salagnac >Priority: Minor > Labels: newdev, pull-request-available > Fix For: main (10.0) > > Time Spent: 2h 20m > Remaining Estimate: 0h > > RequestWriter writes XML; some subclasses write other things. This is > terrible API design; the XML choice should be a subclass, RequestWriter > should be abstract (or an interface). > While we're at this, the XML generation is kind of split into multiple > places; it should be consolidated: UpdateRequest & ClientUtils have XML > generation methods. Those methods should move to the new XmlRequestWriter. > BinaryRequestWriter should probably be final and/or ensure the CBOR one does > not subclass it, which is weird since CBOR != "javabin". > Be sure to note this refactoring in the update notes since SolrJ users will > be impacted. -- 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-17670) Fix unnecessary memory allocation caused by a large reRankDocs param
[
https://issues.apache.org/jira/browse/SOLR-17670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933681#comment-17933681
]
ASF subversion and git services commented on SOLR-17670:
Commit 76c09a35dba42913a6bcb281b52b00f87564624a in solr's branch
refs/heads/deprecations from jiabao.gao
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=76c09a35dba ]
SOLR-17670: Fix unnecessary memory allocation caused by a large reRankDocs
param (#3181)
> Fix unnecessary memory allocation caused by a large reRankDocs param
>
>
> Key: SOLR-17670
> URL: https://issues.apache.org/jira/browse/SOLR-17670
> Project: Solr
> Issue Type: Bug
>Reporter: JiaBaoGao
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.8.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The reRank function has a reRankDocs parameter that specifies the number of
> documents to re-rank. I've observed that increasing this parameter to test
> its performance impact causes queries to become progressively slower. Even
> when the parameter value exceeds the total number of documents in the index,
> further increases continue to slow down the query, which is counterintuitive.
>
> Therefore, I investigated the code:
>
> For a query containing re-ranking, such as:
> {code:java}
> {
> "start": "0",
> "rows": 10,
> "fl": "ID,score",
> "q": "*:*",
> "rq": "{!rerank reRankQuery='{!func} 100' reRankDocs=10
> reRankWeight=2}"
> } {code}
>
> The current execution logic is as follows:
> 1. Perform normal retrieval using the q parameter.
> 2. Re-score all documents retrieved in the q phase using the rq parameter.
>
> During the retrieval in phase 1 (using q), a TopScoreDocCollector is created.
> Underneath, this creates a PriorityQueue which contains an Object[]. The
> length of this Object[] continuously increases with reRankDocs without any
> limit.
>
> On my local test cluster with limited JVM memory, this can even trigger an
> OOM, causing the Solr node to crash. I can also reproduce the OOM situation
> using the SolrCloudTestCase unit test.
>
> I think limiting the length of the Object[] array using
> searcher.getIndexReader().maxDoc() at ReRankCollector would resolve this
> issue. This way, when reRankDocs exceeds maxDoc, memory allocation will not
> continue to increase indefinitely.
--
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-16391) Cosmetic improvements and migration to JAX-RS (collection, collection prop, core CRUD APIs)
[
https://issues.apache.org/jira/browse/SOLR-16391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933685#comment-17933685
]
ASF subversion and git services commented on SOLR-16391:
Commit 79503c1afe55beed1bdd6e66a287be1835340cbc in solr's branch
refs/heads/deprecations from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=79503c1afe5 ]
SOLR-16391: Fix CoreStatus NullPointerException
A previous recent commit (5fafab) introduced a NullPointerException when
a Boolean was in a conditional without first checking for 'null'. This
commit fixes this error and another related CoreStatus-related test
failure.
> Cosmetic improvements and migration to JAX-RS (collection, collection prop,
> core CRUD APIs)
> ---
>
> Key: SOLR-16391
> URL: https://issues.apache.org/jira/browse/SOLR-16391
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
>Affects Versions: main (10.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Labels: newdev, pull-request-available
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> As mentioned on SOLR-15781, the v2 API currently has an experimental
> designation, and the community has expressed an interest in using this period
> to update our v2 endpoints to be more REST-ful and consistent. The current
> plan is to follow the specific changes laid out in [this
> spreadsheet|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing],
> though of course nothing there is set in stone and there are still warts to
> be worked out.
> While we're touching the code for these endpoints, we should also convert
> them to JAX-RS framework definitions. (This was initially tracked as a
> separate effort - see SOLR-16370 - but the edit that were required ended up
> overlapping so significantly with the "cosmetic" improvements here that in
> practice it almost always makes sense to do the two together.)
> This ticket plans to tackle making the changes required for Solr's collection
> and collection-prop CRUD APIs, as well as its collection-status APIs. These
> are described in detail in the spreadsheet linked above, but are summarized
> in the tables below for convenience and ease of tracking progress.
> *JAX-RS Conversion and Cosmetic Changes*
> ||API Name||Original Form||Desired Form||Status||Volunteer||
> |-Create Collection-|-POST /api/collections \{create: \{...\}\}-|-POST
> /api/collections \{...\}-|-Finished-|-Jason-|
> |-Get Collection Details-|-N/A-|-GET
> /api/collections/collName?details=specificFlags-|-Finished-|-Jason-|
> |Create Core|POST /api/cores \{"create": \{...\}\}|POST /api/cores
> \{...\}|Open|N/A|
> |Collection Ping/Healthcheck|GET /api/collections/collName/admin/ping|GET
> /api/collections/collName/health|Open|N/A|
> |Is Collection Healthcheck Enabled|GET
> /api/collections/collName/admin/ping?action=STATUS|GET
> /api/collections/collName/health/status|Open|N/A|
> |Enable/Disable Collection Healthcheck|GET
> /api/collections/collName/admin/ping?action=enable\|disable|PUT
> /api/collections/collName/health/status \{"enabled": true\|false\}|Open|N/A|
> |-Delete Collections-|-DELETE /api/collections/collName-|-DELETE
> /api/collections/collName-|-Finished-|-Jason-|
> |-Set Collection Property-|-POST /api/collections/collName
> \{set-collection-property: \{...\}\}-|-PUT
> /api/collections/collName/properties/propName \{"value":
> "someVal"\}-|-Finished-|-Jason-|
> |-Delete Collection Property-|-POST /api/collections/collName
> \{set-collection-property: \{...\}\}-|-DELETE
> /api/collections/collName/properties/propName-|-Finished-|-Jason-|
> *JAX-RS Conversion Only*
> ||API Name||Endpoint||Status||Volunteer||
> |-List Collections-|-GET /api/collections-|-Finished-|-Jason-|
> Some helpful links related to these changes these changes. Should help get
> any interested newcomers started!
> * For detailed information on Solr's current and desired v2 APIs see the
> spreadsheet
> [here|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing]
> * [Discussion of how APIs work in Solr
> (video)|https://www.youtube.com/watch?v=iIpvfXBjDog]
> * [Step-by-step guide to creating
> APIs|https://issues.apache.org/jira/browse/SOLR-15737?focusedCommentId=17617923&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17617923]
> using the JAX-RS v2 API framework
> * [Example PR for a similar change|https://github.com/apache/solr/pull/1679]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.o
[jira] [Commented] (SOLR-17686) Getting the str representation of distributed stage throws when stage is a custom one
[
https://issues.apache.org/jira/browse/SOLR-17686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933691#comment-17933691
]
ASF subversion and git services commented on SOLR-17686:
Commit e668dceb6bec0b838d5f1e045483432abd6b6612 in solr's branch
refs/heads/deprecations from Jeanie Lam
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=e668dceb6be ]
SOLR-17686: Rename SearchHandler.stageInEnglish to stageToString and make it
protected and non-static (#3224)
> Getting the str representation of distributed stage throws when stage is a
> custom one
> -
>
> Key: SOLR-17686
> URL: https://issues.apache.org/jira/browse/SOLR-17686
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.8
>Reporter: Jeanie Lam
>Assignee: Christine Poerschke
>Priority: Minor
> Labels: pull-request-available
> Fix For: 9.9, 9.8.1
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> [https://github.com/apache/solr/pull/2859] from SOLR-17151 adds a new private
> static method
> {{[stageInEnglish|https://github.com/apache/solr/blob/8bf0100e502ade4b8161e4b90f762b117a6ef442/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L714]}}
> that converts a distributed stage to a string for logging purposes.
> This method throws when the stage is not one recognized by the switch
> statement, i.e. a custom stage.
> A solution could be to make {{stageInEnglish}} protected and non-static
> instead so users with custom stage(s) could override it.
--
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-17309) Enhance Cert Authentication plugin with flexible cert principal resolution
[
https://issues.apache.org/jira/browse/SOLR-17309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933696#comment-17933696
]
ASF subversion and git services commented on SOLR-17309:
Commit 9d2118bafb885f983d033c85c8a3accac11c0faa in solr's branch
refs/heads/deprecations from Lamine
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=9d2118bafb8 ]
SOLR-17309: Enhance certificate based authentication plugin with flexible cert
principal resolution (#3029)
-
Co-authored-by: Lamine Idjeraoui
Co-authored-by: Eric Pugh
> Enhance Cert Authentication plugin with flexible cert principal resolution
> --
>
> Key: SOLR-17309
> URL: https://issues.apache.org/jira/browse/SOLR-17309
> Project: Solr
> Issue Type: Improvement
>Reporter: Lamine
>Priority: Minor
> Labels: pull-request-available
> Fix For: 9.9
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> TL;DR
> This the first part of a broader contribution to enhance CertAuthPlugin to
> support _Principal_ resolution, identity resolution and validation.
> This part deals with _Principal_ resolution.
> —
> Solr supports certificate-based authentication (mTLS) via the CertAuthPlugin.
> However, the feature offers limited flexibility. In fact, the class contains
> minimal code, primarily deferring certificate validation to Jetty and
> extracting the _Principal_ from the subject's Distinguish Name (DN). The
> Authorization plugin then maps the extracted _Principal_ to a role.
> I've identified a couple of issues with this approach, as well as potential
> areas for enhancement:
> *1- Issues with Using DN*
> - {*}Length and precision{*}: The DN is lengthy and requires an exact match
> for roles mapping. Even a minor discrepancy, like an extra space, or order of
> attributes (RDN), can break the mapping.
> - {*}One DN per certificate{*}: If different certificates are used for
> different hosts in a cluster, each DN has to be mapped separately to a
> particular role, complicating role mapping and increasing risks of errors.
> - {*}Not customizable{*}: The current implementation doesn't allow operators
> to adapt the Principal extracting to their specific needs.
> - {*}Bad user experience{*}: When logged into Solr Admin UI using
> CertAuthPlugin the whole DN is displayed on the left menu as the 'username'.
> _*Proposed Solution for DN Issues:*_
> - Extraction flexibility: Grant operators the ability to specify the data
> they wish to extract for the {_}Principal{_}, based on a defined path (for
> example: _SUBJECT.DN_ (default), {_}SAN.URI{_}, {_}SAN.email{_}, etc.).
> - Use of delimiters: Introduce optional delimiters (start and end) or
> prefix/suffix to extract only the necessary data from a field, for example a
> group ID.
> **
--
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-17684) Issue in SolrJ Reference Guide (Ping) - Incorrect Status Retrieval
[
https://issues.apache.org/jira/browse/SOLR-17684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933692#comment-17933692
]
ASF subversion and git services commented on SOLR-17684:
Commit ac3d349dac530cf1001d5113fc21b0fd641cc9d5 in solr's branch
refs/heads/deprecations from Umut Saribiyik
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=ac3d349dac5 ]
SOLR-17684: SolrJ Reference Guide (Ping) - Incorrect Status Retrieval (#3237)
- Update ping.adoc with references from unit test.
- Add unit test to illustrate the usage of the ping response.
> Issue in SolrJ Reference Guide (Ping) - Incorrect Status Retrieval
> --
>
> Key: SOLR-17684
> URL: https://issues.apache.org/jira/browse/SOLR-17684
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.8
>Reporter: Umut Saribiyik
>Priority: Minor
> Labels: guide, monitor, pingrequest, pull-request-available,
> reference, solrj
> Attachments: image-2025-02-26-13-29-31-289.png
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The SolrJ Reference Guide provides incorrect examples for retrieving the ping
> status of a collection.
> [https://solr.apache.org/guide/solr/9_8/deployment-guide/ping.html]
> *Issues:*
> # pingResponse.getStatus() returns the status of the ping request itself
> (status=0), not the collection's ping status ("OK").
> # Since getResponse() returns a NamedList, the value must be
> explicitly cast to a String or converted using .toString().
>
>
> *Correction:*
> The correct way to retrieve the collection's ping status:
> {code:java}
> String status = (String) process.getResponse().get("status");
> String status = process.getResponse().get("status").toString();
> {code}
>
>
>
--
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-17438) releaseWizard: remove refs to people.apache.org/home.apache.org
[ https://issues.apache.org/jira/browse/SOLR-17438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933693#comment-17933693 ] ASF subversion and git services commented on SOLR-17438: Commit 4acc1dfc5364fd153e69cd1cda4c80c2bf26d7f8 in solr's branch refs/heads/deprecations from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=solr.git;h=4acc1dfc536 ] SOLR-17438 ReleaseWizard to resolve committer GPG key from whimsy (#3145) > releaseWizard: remove refs to people.apache.org/home.apache.org > --- > > Key: SOLR-17438 > URL: https://issues.apache.org/jira/browse/SOLR-17438 > Project: Solr > Issue Type: Task > Components: release-scripts >Reporter: David Smiley >Assignee: Jan Høydahl >Priority: Blocker > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > The ASF is turning off home.apache.org on September 12th for good. Thus the > release wizard should stop using it to get your key in configure_pgp() -- > https://home.apache.org/keys/committer/%s.asc > FYI see the Lucene [issue|https://github.com/apache/lucene/issues/13647] -- 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-17644) Collection creation fails when replica placement plugin and basic auth are enabled
[
https://issues.apache.org/jira/browse/SOLR-17644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933689#comment-17933689
]
ASF subversion and git services commented on SOLR-17644:
Commit f1badb755d11996742478ff8f19d5fac1951b56e in solr's branch
refs/heads/deprecations from Sanjay Dutt
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=f1badb755d1 ]
SOLR-17644: SolrCloudManager directly uses HttpSolrClientProvider's client,
resolving missing auth listeners (#3208)
Co-authored-by: David Smiley
> Collection creation fails when replica placement plugin and basic auth are
> enabled
> --
>
> Key: SOLR-17644
> URL: https://issues.apache.org/jira/browse/SOLR-17644
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.8
>Reporter: Colvin Cowie
>Assignee: Sanjay Dutt
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.8.1
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> In Solr 9.8 and latest, collection creation fails when the replica placement
> plugin and authentication are both configured. See
> [https://the-asf.slack.com/archives/CEKUCUNE9/p1738152813677179] for more info
>
> Stacktrace:
> {quote}2025-01-29 11:42:40.638 WARN (OverseerThreadFactory-22-thread-1)
> [c:main_index s: r: x: t:] o.a.s.c.s.i.SolrClientNodeStateProvider could not
> get tags from node localhost:8983_solr =>
> org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException:
> Error from server at
> http://localhost:8983/solr/admin/metrics
> : Expected mime type in [application/octet-stream,
> application/vnd.apache.solr.javabin] but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401 require authentication
>
> URI:/solr/admin/metrics
> STATUS:401
> MESSAGE:require authentication
> SERVLET:default
>
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClientBase.checkContentType(HttpSolrClientBase.java:341)
> org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException:
> Error from server at
> http://localhost:8983/solr/admin/metrics
> : Expected mime type in [application/octet-stream,
> application/vnd.apache.solr.javabin] but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401 require authentication
>
> URI:/solr/admin/metrics
> STATUS:401
> MESSAGE:require authentication
> SERVLET:default
>
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClientBase.checkContentType(HttpSolrClientBase.java:341)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClientBase.processErrorsAndResponse(HttpSolrClientBase.java:227)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.processErrorsAndResponse(Http2SolrClient.java:621)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:542)
> ~[?:?]
> at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:279)
> ~[?:?]
> at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:295)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.requestWithBaseUrl(Http2SolrClient.java:604)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$RemoteCallCtx.invoke(SolrClientNodeStateProvider.java:292)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$RemoteCallCtx.invokeWithRetry(SolrClientNodeStateProvider.java:255)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:190)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.NodeValueFetcher.getRemotePropertiesAndMetrics(NodeValueFetcher.java:125)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.NodeValueFetcher.getTags(NodeValueFetcher.java:187)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:114)
> ~[?:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:106)
> ~[?:?]
> at
> org.apache.solr.cluster.placement.impl.AttributeFetcherImpl.fetchAttributes(AttributeFetcherImpl.java:149)
> ~[?:?]
> at
> org.apache.solr.cluster.placement.plugins.AffinityPlacementFactory$AffinityPlacementPlugin.getBaseWeightedNodes(AffinityPlacementFactory.java:284)
> ~[?:?]
> at
> org.apache.solr.cluster.placement.plugins.OrderedNodePlacementPlugin.getWeightedNodes(OrderedNodePlacementPlugin.java:316)
> ~[?:?]
> at
> org.apache.solr.cluster.placement.plugins.OrderedNodePlacementPlugin.computePlacements(OrderedNodePlacementPlugin.java:88)
> ~[?:?]
> at
> org.apache.solr.cluster.placement.impl.Pl
[jira] [Commented] (SOLR-17623) SimpleOrderedMap should implement Map
[ https://issues.apache.org/jira/browse/SOLR-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933690#comment-17933690 ] ASF subversion and git services commented on SOLR-17623: Commit 046677d10b384dd399da53b89d19ab457ab5e6b1 in solr's branch refs/heads/deprecations from David Smiley [ https://gitbox.apache.org/repos/asf?p=solr.git;h=046677d10b3 ] SOLR-17623: SimpleOrderedMap equals, hashCode (and for Map.Entry) (#3214) And ensure a NamedList is never equal to a SimpleOrderedMap > SimpleOrderedMap should implement Map > - > > Key: SOLR-17623 > URL: https://issues.apache.org/jira/browse/SOLR-17623 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Priority: Major > Labels: newdev, pull-request-available > Fix For: 9.9 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > SimpleOrderedMap is semantically a Map; it should implement Map. > Why: This will help us transition away from NamedList (it's superclass) in a > number of places, since many (most?) places that are defined to return a > NamedList could actually be declared to be a SimpleOrderedMap and eventually > simply Map. > There's some risk that code somewhere gets this Map, a large one, and then > assumes it has better than O(N) lookup, which it doesn't provide. Perhaps a > Javadoc warning will do. -- 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-17678 Add support to return original score ( the query score ) in case of r… [solr]
sijuv commented on code in PR #3222: URL: https://github.com/apache/solr/pull/3222#discussion_r1983912923 ## solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java: ## @@ -194,7 +193,6 @@ public class SolrIndexSearcher extends IndexSearcher implements Closeable, SolrI private final StatsCache statsCache; - private Set metricNames = ConcurrentHashMap.newKeySet(); Review Comment: this is an unused field -- 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
