[jira] [Updated] (SOLR-17590) Complete Major changes and Upgrade Notes in RefGuide for 9.8.0

[Anshum Gupta (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-17590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anshum Gupta updated SOLR-17590:

Fix Version/s: 9.8

> Complete Major changes and Upgrade Notes in RefGuide for 9.8.0
> --
>
> Key: SOLR-17590
> URL: https://issues.apache.org/jira/browse/SOLR-17590
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: 9.8
>
>
> Blocker to make sure a 9.8.0 release is not announced before the reference 
> guide is complete.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

[jira] [Created] (SOLR-17590) Complete Major changes and Upgrade Notes in RefGuide for 9.8.0

[Anshum Gupta (Jira)]

Anshum Gupta created SOLR-17590:
---

 Summary: Complete Major changes and Upgrade Notes in RefGuide for 
9.8.0
 Key: SOLR-17590
 URL: https://issues.apache.org/jira/browse/SOLR-17590
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Anshum Gupta
Assignee: Anshum Gupta


Blocker to make sure a 9.8.0 release is not announced before the reference 
guide is complete.



--
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-16390: fix flaky test ClusterPropsAPITest.testClusterPropertyOpsAllGood [solr]

[via GitHub]

psalagnac opened a new pull request, #2901:
URL: https://github.com/apache/solr/pull/2901

   
   https://issues.apache.org/jira/browse/SOLR-16390
   (linking to the Jira that introduced the test)
   
   
   
   
   
   # Description
   
   The test fails when SSL is enabled, because of testing framework that set 
'urlScheme' cluster property.
   
   I was looking at the failure in another PR, and it seems this test fails 
quite often since #2788. I don't think it is tracked somewhere else.
   
   # Solution
   
This change updates the test to ignore existing cluster properties.
   
   # Tests
   
   n/a
   
   


-- 
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] Solr Restore Space Considerations in Kubernetes [solr-operator]

[via GitHub]

gerlowskija commented on issue #726:
URL: https://github.com/apache/solr-operator/issues/726#issuecomment-2532364686

   (Hi @mchennupati - it looks like the formatting on your post mangled a few 
things, so apologies if I'm missing something.)
   
   afaict your question isn't necessarily related to using the operator for 
restores, it's just a question about the disk and network costs of restoring a 
Solr collection?  Assuming I've got that right - a better place to ask in the 
future would be our project's "user" mailing list: us...@solr.apache.org.  
Please subscribe and ask similar questions there going forward!
   
   To your specific question: if you're restoring data to an existing 
collection, Solr will have each replica fetch data from the backup repository.  
(So if you have three replicas each fetching a 100gb index, you'll pull 300gb 
from GCS).  Restores to a new collection work slightly differently, with only 
one replica fetching the index and then distributing it within your Solr 
cluster as needed.  So the network impact of restores can be tuned a little bit.
   
   In terms of disk space though - ultimately all replicas of a shard will need 
a full copy of that shard's data, which sounds like 665GB in your case.


-- 
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] Solr Restore Space Considerations in Kubernetes [solr-operator]

[via GitHub]

gerlowskija closed issue #726: Solr Restore Space Considerations in Kubernetes
URL: https://github.com/apache/solr-operator/issues/726


-- 
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-16390) Cosmetic improvements and migration to JAX-RS (v2 cluster and clusterprop APIs)

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-16390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904630#comment-17904630
 ] 

ASF subversion and git services commented on SOLR-16390:


Commit e105547be5b36994703d3ed0d38413c65f0b8349 in solr's branch 
refs/heads/main from Pierre Salagnac
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=e105547be5b ]

SOLR-16390: fix flaky test ClusterPropsAPITest.testClusterPropertyOpsAllGood 
(#2901)

The test fails when SSL in enabled, because of testing framework that
set 'urlScheme' cluster property. This change updates the test to ignore
existing cluster properties.

> Cosmetic improvements and migration to JAX-RS (v2 cluster and clusterprop 
> APIs)
> ---
>
> Key: SOLR-16390
> URL: https://issues.apache.org/jira/browse/SOLR-16390
> Project: Solr
>  Issue Type: Sub-task
>  Components: documentation, v2 API
>Affects Versions: main (10.0)
>Reporter: Jason Gerlowski
>Priority: Major
>  Labels: newdev, pull-request-available
>  Time Spent: 4h
>  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.
> This ticket plans to tackle making the changes required for Solr's "Cluster" 
> and "cluster-prop" APIs.  These APIs are described in detail in the 
> spreadsheet linked above, but are summarized in the table below for 
> convenience and easier tracking.
> 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.)
> *Cosmetic Changes and JAX-RS Conversion*
> ||API Name||Original Form||Desired Form||Status||Volunteer||
> |Upsert ClusterProp|POST /api/cluster \{"set-property": \{...\}\}|PUT 
> /api/cluster/properties/propName \{"value": "propVal"\}|Open|N/A|
> |Upsert ClusterProp (Potentially Nested)|POST /api/cluster 
> \{"set-obj-property": \{...\}\}|PUT /api/cluster/properties \{...\}|Open|N/A|
> |Delete ClusterProp|POST /api/cluster \{"set-property": \{"name": "foo", 
> "value": ""\}\}|DELETE /api/cluster/properties/propName|Open|N/A|
> |Delete Single Async Status|DELETE /api/cluster/command-status/123|DELETE 
> /api/cluster/commands/123|Open|N/A|
> |Delete All Async Status|DELETE /api/cluster/command-status|DELETE 
> /api/cluster/commands|Open|N/A|
> |Get Single Async Status|GET /api/cluster/command-status/123|GET 
> /api/cluster/commands/123|Open|N/A|
> |Create rate-limiter|POST /api/cluster/ \{"set-ratelimiter": \{...\}\}|POST 
> /api/cluster/ratelimiter \{...\}|Open|N/A|



--
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-16390: fix flaky test ClusterPropsAPITest.testClusterPropertyOpsAllGood [solr]

[via GitHub]

psalagnac merged PR #2901:
URL: https://github.com/apache/solr/pull/2901


-- 
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-16390: fix flaky test ClusterPropsAPITest.testClusterPropertyOpsAllGood [solr]

[via GitHub]

psalagnac commented on code in PR #2901:
URL: https://github.com/apache/solr/pull/2901#discussion_r1878857962


##
solr/core/src/test/org/apache/solr/handler/admin/api/ClusterPropsAPITest.java:
##
@@ -103,10 +109,9 @@ public void testClusterPropertyOpsAllGood() throws 
Exception {
   // List Properties, this time there should be 1
   o = Utils.executeGET(client.getHttpClient(), baseUrlV2ClusterProps, 
Utils.JSONCONSUMER);
   assertNotNull(o);
-  assertEquals(1, ((List) getObjectByPath(o, true, 
"clusterProperties")).size());
-  assertEquals(
-  testClusterProperty,
-  (String) ((List) getObjectByPath(o, true, 
"clusterProperties")).get(0));
+  assertEquals(initCount + 1, ((List) getObjectByPath(o, true, 
"clusterProperties")).size());

Review Comment:
   Good point. I'm updating the test to check the property exists instead of 
counting.



-- 
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] [Comment Edited] (SOLR-17589) First use of PUT/POST request with HttpJdkSolrClient generates error log entry on solr server due to initial HEAD request

[Paul Blanchaert (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904634#comment-17904634
 ] 

Paul Blanchaert edited comment on SOLR-17589 at 12/10/24 10:15 PM:
---

[~jdyer] 

If we can modify the HEAD request to send an empty json object as payload, the 
problem should be solved...

We can reproduce with curl:

{{curl -X HEAD --location "http://localhost:8983/solr/collection1/update"}}

--> raises error

While

{{curl -X HEAD --location "http://localhost:8983/solr/collection1/update"}}
{{    -H "Content-Type: application/json" }}
{{    -d '{}'}}

--> doesn't raise error

This goes for --http2, --http2-prior-knowledge and --http1.1

Content-Type should be one of: [application/xml, application/csv, 
application/json, text/json, text/csv, text/xml, application/javabin, 
application/cbor]

Could this bring us closer to a solution?


was (Author: p...@search-solutions.net):
[~jdyer] 

If we can modify the HEAD request to send an empty json object as payload, the 
problem should be solved...

We can reproduce with curl:

{{curl -X HEAD --location "http://localhost:8983/solr/collection1/update"}}

--> raises error

While

{{curl -X HEAD --location "http://localhost:8983/solr/collection1/update"}}
{{    -H "Content-Type: application/json" }}
    -d '{}'

--> doesn't raise error

This goes for --http2, --http2-prior-knowledge and --http1.1

Content-Type should be one of: [application/xml, application/csv, 
application/json, text/json, text/csv, text/xml, application/javabin, 
application/cbor]

Could this bring us closer to a solution?

> First use of PUT/POST request with HttpJdkSolrClient generates error log 
> entry on solr server due to initial HEAD request
> -
>
> Key: SOLR-17589
> URL: https://issues.apache.org/jira/browse/SOLR-17589
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 9.7
>Reporter: Paul Blanchaert
>Priority: Minor
>
> The first call of the maybeTryHeadRequest of the HttpJdkSolrClient (used in 
> the preparePutOrPost) causes an ERROR log entry in the solr server log even 
> while the "HEAD" request is considered successful in the client.
> The client only performs this request once.
> The error on server side is due to the "empty" request: "missing content 
> stream"
> 2024-12-10 08:31:48 2024-12-10 07:31:48.877 INFO  (qtp1380924218-23-solr-123) 
> [c:collection1 s:shard1 r:core_node2 x:collection1_shard1_replica_n1 
> t:solr-123] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update 
> params={}{} 0 0
> 2024-12-10 08:31:48 2024-12-10 07:31:48.877 ERROR (qtp1380924218-23-solr-123) 
> [c:collection1 s:shard1 r:core_node2 x:collection1_shard1_replica_n1 
> t:solr-123] o.a.s.h.RequestHandlerBase Client exception => 
> org.apache.solr.common.SolrException: missing content stream
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:93)
> 2024-12-10 08:31:48 org.apache.solr.common.SolrException: missing content 
> stream
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:93)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:226)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576) ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:208)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:243)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:213) 
> ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210) 
> ~[jetty-servlet-10.0.22.jar:10.0.22]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

--

[jira] [Comment Edited] (SOLR-17589) First use of PUT/POST request with HttpJdkSolrClient generates error log entry on solr server due to initial HEAD request

[Paul Blanchaert (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904634#comment-17904634
 ] 

Paul Blanchaert edited comment on SOLR-17589 at 12/10/24 10:15 PM:
---

[~jdyer] 

If we can modify the HEAD request to send an empty json object as payload, the 
problem should be solved...

We can reproduce with curl:

{{curl -X HEAD --location "http://localhost:8983/solr/collection1/update"}}

--> raises error

While

{{curl -X HEAD --location "http://localhost:8983/solr/collection1/update"}}
{{    -H "Content-Type: application/json" }}
    -d '{}'

--> doesn't raise error

This goes for --http2, --http2-prior-knowledge and --http1.1

Content-Type should be one of: [application/xml, application/csv, 
application/json, text/json, text/csv, text/xml, application/javabin, 
application/cbor]

Could this bring us closer to a solution?


was (Author: p...@search-solutions.net):
[~jdyer] 

If we can modify the HEAD request to send an empty json object as payload, the 
problem should be solved...

We can reproduce with curl:

{{curl -X HEAD --location "http://localhost:8983/solr/collection1/update"}}

--> raises error

While

{{curl -X HEAD --location "http://localhost:8983/solr/collection1/update"; \}}
{{    -H "Content-Type: application/json" \}}
{{    -d '{}'}}

--> doesn't raise error

Content-Type should be one of: [application/xml, application/csv, 
application/json, text/json, text/csv, text/xml, application/javabin, 
application/cbor]

Could this bring us closer to a solution?

> First use of PUT/POST request with HttpJdkSolrClient generates error log 
> entry on solr server due to initial HEAD request
> -
>
> Key: SOLR-17589
> URL: https://issues.apache.org/jira/browse/SOLR-17589
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 9.7
>Reporter: Paul Blanchaert
>Priority: Minor
>
> The first call of the maybeTryHeadRequest of the HttpJdkSolrClient (used in 
> the preparePutOrPost) causes an ERROR log entry in the solr server log even 
> while the "HEAD" request is considered successful in the client.
> The client only performs this request once.
> The error on server side is due to the "empty" request: "missing content 
> stream"
> 2024-12-10 08:31:48 2024-12-10 07:31:48.877 INFO  (qtp1380924218-23-solr-123) 
> [c:collection1 s:shard1 r:core_node2 x:collection1_shard1_replica_n1 
> t:solr-123] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update 
> params={}{} 0 0
> 2024-12-10 08:31:48 2024-12-10 07:31:48.877 ERROR (qtp1380924218-23-solr-123) 
> [c:collection1 s:shard1 r:core_node2 x:collection1_shard1_replica_n1 
> t:solr-123] o.a.s.h.RequestHandlerBase Client exception => 
> org.apache.solr.common.SolrException: missing content stream
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:93)
> 2024-12-10 08:31:48 org.apache.solr.common.SolrException: missing content 
> stream
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:93)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:226)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576) ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:208)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:243)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:213) 
> ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210) 
> ~[jetty-servlet-10.0.22.jar:10.0.22]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SOLR-5374) Support user configured doc-centric versioning rules

[David Smiley (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904652#comment-17904652
 ] 

David Smiley commented on SOLR-5374:


[~hossman]  in the description you stated:
{quote}I realized it requires a uniqueness constraint across all update 
commands, that would make it impossible to allow multiple independent documents 
to have the same _version_
{quote}
I don't suppose you could elaborate or have a pointer? My ask may be laughable 
after 11 years but it doesn't hurt to ask.  There's no good documentation on 
the design of \_version\_ and I might try to retroactively document this.

 

> Support user configured doc-centric versioning rules
> 
>
> Key: SOLR-5374
> URL: https://issues.apache.org/jira/browse/SOLR-5374
> Project: Solr
>  Issue Type: Improvement
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: 4.6, 6.0
>
> Attachments: SOLR-5374.patch, SOLR-5374.patch, SOLR-5374.patch, 
> SOLR-5374.patch, SOLR-5374.patch, SOLR-5374.patch
>
>
> The existing optimistic concurrency features of Solr can be very handy for 
> ensuring that you are only updating/replacing the version of the doc you 
> think you are updating/replacing, w/o the risk of someone else 
> adding/removing the doc in the mean time -- but I've recently encountered 
> some situations where I really wanted to be able to let the client specify an 
> arbitrary version, on a per document basis, (ie: generated by an external 
> system, or perhaps a timestamp of when a file was last modified) and ensure 
> that the corresponding document update was processed only if the "new" 
> version is greater then the "old" version -- w/o needing to check exactly 
> which version is currently in Solr.  (ie: If a client wants to index version 
> 101 of a doc, that update should fail if version 102 is already in the index, 
> but succeed if the currently indexed version is 99 -- w/o the client needing 
> to ask Solr what the current version)
> The idea Yonik brought up in SOLR-5298 (letting the client specify a 
> {{\_new\_version\_}} that would be used by the existing optimistic 
> concurrency code to control the assignment of the {{\_version\_}} field for 
> documents) looked like a good direction to go -- but after digging into the 
> way {{\_version\_}} is used internally I realized it requires a uniqueness 
> constraint across all update commands, that would make it impossible to allow 
> multiple independent documents to have the same {{\_version\_}}.
> So instead I've tackled the problem in a different way, using an 
> UpdateProcessor that is configured with user defined field to track a 
> "DocBasedVersion" and uses the RTG logic to figure out if the update is 
> allowed.



--
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-17583: Bring back documentation for Adding Custom Expressions [solr]

[via GitHub]

mkhludnev commented on PR #2903:
URL: https://github.com/apache/solr/pull/2903#issuecomment-2533929822

   Thanks for PR. Have you tried to generate the doc? I'm not sure if the 
reference syntax hasn't changed from those times, and link might be broken. 


-- 
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-14680) Provide simple interfaces to our concrete SolrCloud classes

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904600#comment-17904600
 ] 

ASF subversion and git services commented on SOLR-14680:


Commit 364c0afb5bc98460713e6ede071d375058e8de9c in solr's branch 
refs/heads/branch_9x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=364c0afb5bc ]

SOLR-14680: Deprecating org.apache.solr.cluster.api, includes NamedList methods 
(#2856)

NamedList: deprecated methods: forEachEntry, forEachKey, abortableForEachKey, 
abortableForEach,
 asMap (no-arg only), get(key, default) -- all come from the SimpleMap 
interface.  Added getOrDefault.
Deprecated the SimpleMap interface as well as the entirety of the SolrJ package 
org.apache.solr.cluster.api, which wasn't used except for SimpleMap.

Includes some trivial refactorings to not call those deprecated methods.
Includes internal changes to ConfigNode and friends so as to not use SimpleMap.

(cherry picked from commit c80d41597c83c8c73634144ab8c55f8002dd101d)


> Provide simple interfaces to our concrete SolrCloud classes
> ---
>
> Key: SOLR-14680
> URL: https://issues.apache.org/jira/browse/SOLR-14680
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
>  Labels: clean-api, pull-request-available
>  Time Spent: 13h 10m
>  Remaining Estimate: 0h
>
> All our current implementations of SolrCloud such as 
> # ClusterState
> # DocCollection
> # Slice
> # Replica
> etc are concrete classes. Providing alternate implementations or wrappers is 
> extremely difficult. 
> SOLR-14613 is attempting to create  such interfaces to make their sdk simpler
> The objective is not to have a comprehensive set of methods in these 
> interfaces. We will start out with a subset of required interfaces. We 
> guarantee is that signatures of methods in these interfaces will not be 
> deleted/changed . But we may add more methods as and when it suits us



--
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-17561) DocCollection, remove getReplicas() and getReplicas(EnumSet)

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904601#comment-17904601
 ] 

ASF subversion and git services commented on SOLR-17561:


Commit e732aa84dc519a2f8238ee5af78e11fce4bc8221 in solr's branch 
refs/heads/branch_9x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=e732aa84dc5 ]

SOLR-17561: Deprecations in ClusterState, DocCollection, Replica (#2898)

Non-essential methods that will go away in Solr 10.  Might add additional 
methods later to address some conveniences these offer.

(cherry picked from commit 2d3a8d9954a45c0eb1bbaa77b29f51ce314c1849)


> DocCollection, remove getReplicas() and getReplicas(EnumSet)
> 
>
> Key: SOLR-17561
> URL: https://issues.apache.org/jira/browse/SOLR-17561
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, SolrJ
>Reporter: David Smiley
>Priority: Major
>  Labels: newdev, pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {{DocCollection.getReplicas()}} and {{getReplicas(EnumSet return new collections, which is counterintuitive based on their name.  For 
> many callers, this is a needless extra cost too.  They should be removed in 
> 10, deprecated in 9.
> Instead, consider adding replicaStream().  Some callers that are more 
> performance sensitive might simply want to double-for-loop over Slice then 
> Replicas.



--
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-16390: fix flaky test ClusterPropsAPITest.testClusterPropertyOpsAllGood [solr]

[via GitHub]

dsmiley commented on code in PR #2901:
URL: https://github.com/apache/solr/pull/2901#discussion_r1878613448


##
solr/core/src/test/org/apache/solr/handler/admin/api/ClusterPropsAPITest.java:
##
@@ -103,10 +109,9 @@ public void testClusterPropertyOpsAllGood() throws 
Exception {
   // List Properties, this time there should be 1
   o = Utils.executeGET(client.getHttpClient(), baseUrlV2ClusterProps, 
Utils.JSONCONSUMER);
   assertNotNull(o);
-  assertEquals(1, ((List) getObjectByPath(o, true, 
"clusterProperties")).size());
-  assertEquals(
-  testClusterProperty,
-  (String) ((List) getObjectByPath(o, true, 
"clusterProperties")).get(0));
+  assertEquals(initCount + 1, ((List) getObjectByPath(o, true, 
"clusterProperties")).size());

Review Comment:
   IMO this test shouldn't bother checking the size; it need only check that 
the entry it's expecting is there or is not there.  Hamcrest test utils helps.  
I did this a day or two ago in this test: 
https://github.com/apache/solr/blob/2d3a8d9954a45c0eb1bbaa77b29f51ce314c1849/solr/solrj/src/test/org/apache/solr/client/solrj/impl/ClusterStateProviderTest.java#L165



-- 
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] Enabling test-retry-gradle-plugin [solr]

[via GitHub]

dsmiley commented on PR #2665:
URL: https://github.com/apache/solr/pull/2665#issuecomment-2532620288

   I was hoping to visit Gradle Enterprise today to browse the failures, 
differentiated from flaky tests.  But some failures were deemed such after 
executing the test only one time.  For example see: 
https://ge.apache.org/s/qcptlo6laqo5g/tests/task/:solr:core:test/details/org.apache.solr.search.TestThinCache/testSimple?top-execution=1
   Do you have any insights @iamsanjay  on why this is?  If we could ensure we 
repeat failures to differentiate failure from flaky, it'd be a major step 
forward to get to the point on notifying people/the-project for repeatable 
failures.  We don't do this today because we don't yet differentiate, and too 
many are flaky.


-- 
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-17589) First use of PUT/POST request with HttpJdkSolrClient generates error log entry on solr server due to initial HEAD request

[James Dyer (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904617#comment-17904617
 ] 

James Dyer commented on SOLR-17589:
---

[~p...@search-solutions.net] This is a known issue.  The HEAD request is a 
workaround for an incompatibility between the JDK client and Jetty, under which 
Solr runs.  See [1] and [2] for more details.  When developing this, I did not 
like it that it generated an ugly error in the log either, but I did not think 
of a better solution at the time.  I was looking for something lightweight that 
would work no matter how Solr is configured.  I had also considered sending a 
request to the ping request handler.  I do not remember why i did not go with 
the ping, but it might be that it can be disabled and/or moved to a different 
path from the default via configuration.

We could modify the server side to better handle HEAD requests, or maybe there 
is something better we could do on the client side?  Concrete suggestions and 
especially PRs are welcome!

-
[1] https://bugs.openjdk.org/browse/JDK-8287589
[2] https://github.com/jetty/jetty.project/issues/9998

> First use of PUT/POST request with HttpJdkSolrClient generates error log 
> entry on solr server due to initial HEAD request
> -
>
> Key: SOLR-17589
> URL: https://issues.apache.org/jira/browse/SOLR-17589
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 9.7
>Reporter: Paul Blanchaert
>Priority: Minor
>
> The first call of the maybeTryHeadRequest of the HttpJdkSolrClient (used in 
> the preparePutOrPost) causes an ERROR log entry in the solr server log even 
> while the "HEAD" request is considered successful in the client.
> The client only performs this request once.
> The error on server side is due to the "empty" request: "missing content 
> stream"
> 2024-12-10 08:31:48 2024-12-10 07:31:48.877 INFO  (qtp1380924218-23-solr-123) 
> [c:collection1 s:shard1 r:core_node2 x:collection1_shard1_replica_n1 
> t:solr-123] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update 
> params={}{} 0 0
> 2024-12-10 08:31:48 2024-12-10 07:31:48.877 ERROR (qtp1380924218-23-solr-123) 
> [c:collection1 s:shard1 r:core_node2 x:collection1_shard1_replica_n1 
> t:solr-123] o.a.s.h.RequestHandlerBase Client exception => 
> org.apache.solr.common.SolrException: missing content stream
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:93)
> 2024-12-10 08:31:48 org.apache.solr.common.SolrException: missing content 
> stream
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:93)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:226)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576) ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:208)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:243)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:213) 
> ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210) 
> ~[jetty-servlet-10.0.22.jar:10.0.22]



--
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-17561 Deprecations in ClusterState/DocCollection/Replica [solr]

[via GitHub]

dsmiley merged PR #2898:
URL: https://github.com/apache/solr/pull/2898


-- 
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-14680: Remove SimpleMap (affects NamedList) [solr]

[via GitHub]

dsmiley merged PR #2856:
URL: https://github.com/apache/solr/pull/2856


-- 
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] Adding ObservedGeneration in the CRD [solr-operator]

[via GitHub]

gerlowskija commented on issue #650:
URL: https://github.com/apache/solr-operator/issues/650#issuecomment-2532280060

   > its hard for our automation running in kubernetes cluster to identify 
whether the patch done in the SolrCloud has been successfully deployed in the 
actual instance or not
   
   I guess this is the bit I'm particularly curious about.  The main thing I 
can think of that wouldn't appear in the status would be pod or 
statefulset-level settings like env-vars, resources, etc - is that 
representative of the sort of things you don't have a good way to poll for?  Or 
is there another common example?
   
   My worry I guess is that the observedGeneration/lastTransitionTime approach 
doesn't give enough granularity to be useful in practice.  It wouldn't give any 
way to distinguish between multiple resource changes made in quick succession.  
Or between a truly substantive "status" update and a (e.g.) pod-readiness blip 
(which also impacts SolrCloudStatus afaict).  Even for a substantive update, 
many spec changes require multiple steps and update "status" multiple times 
throughout - so in practice there can be a big gap between "the status changed" 
and "the user-requested change is complete".
   
   It feels like observedGeneration might send a wrong (or at least 
incomplete?) signal to your provisioner/UI much of the time.  Have you thought 
much about those scenarios?  Is there maybe something I'm missing?
   
   I'm not against the approach btw - I just want to make sure it'll work 
before we build.


-- 
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-17587) Prometheus Writer duplicate TYPE information in exposition format

[Matthew Biscocho (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-17587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthew Biscocho updated SOLR-17587:

Summary: Prometheus Writer duplicate TYPE information in exposition format  
(was: Prometheus Writer Duplicate TYPE exposition format)

> Prometheus Writer duplicate TYPE information in exposition format
> -
>
> Key: SOLR-17587
> URL: https://issues.apache.org/jira/browse/SOLR-17587
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 9.7
>Reporter: Matthew Biscocho
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Solr's Prometheus writer duplicates `# TYPE   type>` in it's exposition format for core registry metrics.
> For example this appears twice in it's output:
> {code:java}
> # TYPE solr_metrics_core_average_request_time gauge
> solr_metrics_core_average_request_time{category="ADMIN",collection="foo",core="core_foo_shard9_replica_t351",handler="/admin/file",replica="replica_t351",shard="shard9"}
>  0.0 
> ...
> # TYPE solr_metrics_core_average_request_time gauge{code}
> This is technically not allowed per [Prometheus Exposition 
> format|https://github.com/prometheus/docs/blob/main/content/docs/instrumenting/exposition_formats.md#:~:text=Only%20one%20TYPE%20line%20may%20exist%20for%20a%20given%20metric%20name.]
> This happens because each Dropwizard registry is per core, but for Prometheus 
> compatible exposition format upon exporting, it needs to be 1 registry for 
> all cores on a single host, otherwise there will be duplicate `TYPE` formats 
> even though all metrics are unique for its tags/attributes.
> Funnily enough, prometheus upstream collector does not do this verification 
> and accepts the metrics anyways just fine Solr -> Prometheus -> Grafana.
> But depending on the technologies prometheus exposition verification, this 
> will fail. For example 
> [Telegraf|https://github.com/influxdata/telegraf/blob/master/plugins/inputs/prometheus/README.md]:
> {code:java}
> -12-09T16:56:01Z E! [inputs.prometheus] Error in plugin: error reading 
> metrics for "http://127.0.0.1:8983/solr/admin/metrics?wt=prometheus": 
> decoding response failed: text format parsing error in line 568: second TYPE 
> line for metric name "solr_metrics_core_average_request_time", or TYPE 
> reported after samples {code}
> This shouldn't be a blocker if you are pushing metrics to prometheus 
> collector directly.
>  



--
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-17587: Prometheus Writer duplicate TYPE information in exposition format [solr]

[via GitHub]

mlbiscoc opened a new pull request, #2902:
URL: https://github.com/apache/solr/pull/2902

   https://issues.apache.org/jira/browse/SOLR-17587
   
   
   
   
   # Description
   
   Solr's Prometheus writer duplicates `# TYPE  ` in it's exposition format for `core`registry metrics. 
   
   This is an illegal format and depending on the technologies prometheus 
exposition verification for example `Telegraf`, this will fail. For Prometheus 
server itself, this still passes and collects the metrics just fine for some 
reason.
   
   This is because the Prometheus Writer takes Dropwizard registries and 
exports them to Prometheus Registries to expose them in Prometheus format. Solr 
creates Dropwizard registry for every `core` and differentiates the metrics 
that way even though they have the same metric names.
   
   For prometheus, this creates an issue in that metrics should be 
differentiated in it's attributes and tags. So when the metrics are output with 
the Prometheus response writer, it duplicates the `TYPE` information because it 
is a registry for every `core` and doesn't know that the other `core` 
registries have the same metric name and results in duplicate `TYPE` 
information.
   
   # Solution
   
   When metrics are going to be exported for prometheus, we merge all the 
`core` Dropwizard metric registries into a single registry and export that 
registry into prometheus. Duplicate metric names in a registry is not allowed 
in prometheus, so we will also append the core name to the Dropwizard metric to 
differentiate which metric belongs to what core and parse the labels 
accordingly.
   
   This also allowed to clean up and simply some of the 
`SolrPrometheusCoreFormatter` code.
   
   # Tests
   
   Updated the test accordingly with the coreName existing in the Dropwizard 
metric names and it's parsing. 
   
   Also added an assert in `testPrometheusStructureOutput` to confirm there is 
no duplicate `TYPE` information in prometheus output.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ ] I have reviewed the guidelines for [How to 
Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my 
code conforms to the standards described there to the best of my ability.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended, not available for 
branches on forks living under an organisation)
   - [ ] I have developed this patch against the `main` branch.
   - [ ] I have run `./gradlew check`.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Reference 
Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

[jira] [Updated] (SOLR-17587) Prometheus Writer Duplicate TYPE exposition format

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-17587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated SOLR-17587:
--
Labels: pull-request-available  (was: )

> Prometheus Writer Duplicate TYPE exposition format
> --
>
> Key: SOLR-17587
> URL: https://issues.apache.org/jira/browse/SOLR-17587
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 9.7
>Reporter: Matthew Biscocho
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Solr's Prometheus writer duplicates `# TYPE   type>` in it's exposition format for core registry metrics.
> For example this appears twice in it's output:
> {code:java}
> # TYPE solr_metrics_core_average_request_time gauge
> solr_metrics_core_average_request_time{category="ADMIN",collection="foo",core="core_foo_shard9_replica_t351",handler="/admin/file",replica="replica_t351",shard="shard9"}
>  0.0 
> ...
> # TYPE solr_metrics_core_average_request_time gauge{code}
> This is technically not allowed per [Prometheus Exposition 
> format|https://github.com/prometheus/docs/blob/main/content/docs/instrumenting/exposition_formats.md#:~:text=Only%20one%20TYPE%20line%20may%20exist%20for%20a%20given%20metric%20name.]
> This happens because each Dropwizard registry is per core, but for Prometheus 
> compatible exposition format upon exporting, it needs to be 1 registry for 
> all cores on a single host, otherwise there will be duplicate `TYPE` formats 
> even though all metrics are unique for its tags/attributes.
> Funnily enough, prometheus upstream collector does not do this verification 
> and accepts the metrics anyways just fine Solr -> Prometheus -> Grafana.
> But depending on the technologies prometheus exposition verification, this 
> will fail. For example 
> [Telegraf|https://github.com/influxdata/telegraf/blob/master/plugins/inputs/prometheus/README.md]:
> {code:java}
> -12-09T16:56:01Z E! [inputs.prometheus] Error in plugin: error reading 
> metrics for "http://127.0.0.1:8983/solr/admin/metrics?wt=prometheus": 
> decoding response failed: text format parsing error in line 568: second TYPE 
> line for metric name "solr_metrics_core_average_request_time", or TYPE 
> reported after samples {code}
> This shouldn't be a blocker if you are pushing metrics to prometheus 
> collector directly.
>  



--
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] Pods begin to restart as soon auth is enabled [solr-operator]

[via GitHub]

gerlowskija commented on issue #730:
URL: https://github.com/apache/solr-operator/issues/730#issuecomment-2532302560

   Hi @VishwajeetPandeyy - for error messages like "Underlying core creation 
failed while creating collection", you're likely to find more useful 
information in Solr's logs.
   
   The "AUTOCREATED" config name suffix is expected behavior of Solr's.  I'm a 
bit hazy on the context, but I think the intention is that creating a copy of 
the configset is preferred in some scenarios to protect users from unknowingly 
modifying a config that may be used by multiple collections.  See the 
[collection-creation docs 
here](https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create-parameters)
 for more details.
   
   In general - these sort of questions are better suited for Solr's user 
mailing list: us...@solr.apache.org.  Please raise similar questions there 
going forward!


-- 
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] Pods begin to restart as soon auth is enabled [solr-operator]

[via GitHub]

gerlowskija closed issue #730: Pods begin to restart as soon auth is enabled
URL: https://github.com/apache/solr-operator/issues/730


-- 
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-14680) Provide simple interfaces to our concrete SolrCloud classes

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904557#comment-17904557
 ] 

ASF subversion and git services commented on SOLR-14680:


Commit c80d41597c83c8c73634144ab8c55f8002dd101d in solr's branch 
refs/heads/main from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=c80d41597c8 ]

SOLR-14680: Deprecating org.apache.solr.cluster.api, includes NamedList methods 
(#2856)

NamedList: deprecated methods: forEachEntry, forEachKey, abortableForEachKey, 
abortableForEach,
 asMap (no-arg only), get(key, default) -- all come from the SimpleMap 
interface.  Added getOrDefault.  
Deprecated the SimpleMap interface as well as the entirety of the SolrJ package 
org.apache.solr.cluster.api, which wasn't used except for SimpleMap.

Includes some trivial refactorings to not call those deprecated methods.
Includes internal changes to ConfigNode and friends so as to not use SimpleMap.

> Provide simple interfaces to our concrete SolrCloud classes
> ---
>
> Key: SOLR-14680
> URL: https://issues.apache.org/jira/browse/SOLR-14680
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
>  Labels: clean-api, pull-request-available
>  Time Spent: 13h 10m
>  Remaining Estimate: 0h
>
> All our current implementations of SolrCloud such as 
> # ClusterState
> # DocCollection
> # Slice
> # Replica
> etc are concrete classes. Providing alternate implementations or wrappers is 
> extremely difficult. 
> SOLR-14613 is attempting to create  such interfaces to make their sdk simpler
> The objective is not to have a comprehensive set of methods in these 
> interfaces. We will start out with a subset of required interfaces. We 
> guarantee is that signatures of methods in these interfaces will not be 
> deleted/changed . But we may add more methods as and when it suits us



--
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-17561) DocCollection, remove getReplicas() and getReplicas(EnumSet)

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904560#comment-17904560
 ] 

ASF subversion and git services commented on SOLR-17561:


Commit 2d3a8d9954a45c0eb1bbaa77b29f51ce314c1849 in solr's branch 
refs/heads/main from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=2d3a8d9954a ]

SOLR-17561: Deprecations in ClusterState, DocCollection, Replica (#2898)

Non-essential methods that will go away in Solr 10.  Might add additional 
methods later to address some conveniences these offer.

> DocCollection, remove getReplicas() and getReplicas(EnumSet)
> 
>
> Key: SOLR-17561
> URL: https://issues.apache.org/jira/browse/SOLR-17561
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, SolrJ
>Reporter: David Smiley
>Priority: Major
>  Labels: newdev, pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {{DocCollection.getReplicas()}} and {{getReplicas(EnumSet return new collections, which is counterintuitive based on their name.  For 
> many callers, this is a needless extra cost too.  They should be removed in 
> 10, deprecated in 9.
> Instead, consider adding replicaStream().  Some callers that are more 
> performance sensitive might simply want to double-for-loop over Slice then 
> Replicas.



--
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] Solr Restore Space Considerations in Kubernetes [solr-operator]

[via GitHub]

mchennupati commented on issue #726:
URL: https://github.com/apache/solr-operator/issues/726#issuecomment-2532382503

   Thank you for your reply. Yes, I think i didnt quite understand how the
   restore worked, but i figured it out eventually.
   
   One aspect of my question still remains, perhaps its missing documentation.
   The solr operator or a CRD allows one to do a backup. But a similar restore
   doesnt exist or is missing from the docs ?
   
   Thanks !
   
   
   On Tue 10. Dec 2024 at 18:33, Jason Gerlowski ***@***.***>
   wrote:
   
   > (Hi @mchennupati  - it looks like the
   > formatting on your post mangled a few things, so apologies if I'm missing
   > something.)
   >
   > afaict your question isn't necessarily related to using the operator for
   > restores, it's just a question about the disk and network costs of
   > restoring a Solr collection? Assuming I've got that right - a better place
   > to ask in the future would be our project's "user" mailing list:
   > ***@***.*** Please subscribe and ask similar questions there
   > going forward!
   >
   > To your specific question: if you're restoring data to an existing
   > collection, Solr will have each replica fetch data from the backup
   > repository. (So if you have three replicas each fetching a 100gb index,
   > you'll pull 300gb from GCS). Restores to a new collection work slightly
   > differently, with only one replica fetching the index and then distributing
   > it within your Solr cluster as needed. So the network impact of restores
   > can be tuned a little bit.
   >
   > In terms of disk space though - ultimately all replicas of a shard will
   > need a full copy of that shard's data, which sounds like 665GB in your 
case.
   >
   > —
   > Reply to this email directly, view it on GitHub
   > 
,
   > or unsubscribe
   > 

   > .
   > You are receiving this because you were mentioned.Message ID:
   > ***@***.***>
   >
   


-- 
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] Adding ObservedGeneration in the CRD [solr-operator]

[via GitHub]

Shashankft9 commented on issue #650:
URL: https://github.com/apache/solr-operator/issues/650#issuecomment-2532505127

   I hear your concern, maybe I can give some examples of status in other CRs 
that can help explain where I am coming from.
   
   Example 1: 
   the status of a strimzi kafka cr looks something like this:
   ```
   status:
 clusterId: ETqrvQ33S9uL5gshnirFPQ
 conditions:
 - lastTransitionTime: "2024-09-27T07:23:13.389Z"
   message: Exceeded timeout of 30ms while waiting for Deployment 
resource dev-hsp-01-entity-operator
 in namespace hsp-01 to be ready
   reason: TimeoutException
   status: "True"
   type: NotReady
 listeners:
 - addresses:
   - host: hsp-01.sample.com
 port: 30442
   bootstrapServers: hsp-01.sample.com:30442
   name: external
   type: external
 observedGeneration: 1
   ```
   now the idea is that this `observedGeneration` should always match with the 
`metadata.Generation`, this is done so that instead of giving me a granular 
insight, it will give me an overall view that, when I did a change in spec 
(which incremented the `metadata.Generation` value), I can see that the 
operator worked upon it and showed me an error - at some point in time `T` I 
can verify that the operator did actually work on the last CR change by 
comparing the two values. Ofcourse, Its not giving me all the details of what 
changed in between, but it does show me that if in one edit I changed value x, 
y and z, did the operator succesfully process them all or not.
   
   Example 2: 
   We can take a look at something more complex like a knative service CR 
status, where a change in spec, actually causes the knative controllers to 
update 4-5 other CRs in the cluster, which are all captured in a status like 
this:
   
   ```
   status:
 address:
   url: http://healthchecks.metacontroller.svc.cluster.local
 conditions:
 - lastTransitionTime: "2024-03-14T09:31:36Z"
   status: "True"
   type: ConfigurationsReady
 - lastTransitionTime: "2024-03-14T09:31:37Z"
   status: "True"
   type: Ready
 - lastTransitionTime: "2024-03-14T09:31:37Z"
   status: "True"
   type: RoutesReady
 latestCreatedRevisionName: healthchecks-6
 latestReadyRevisionName: healthchecks-6
 observedGeneration: 6
 traffic:
 - latestRevision: true
   percent: 100
   revisionName: healthchecks-6
 url: http://healthchecks.metacontroller.svc.cluster.local
   ```
   now looking at this status, I know the knative controllers worked on the 
last cr spec change, because the `observedGeneration` is equal to whats there 
in the `metadata.Generation`. 
   
   I may not be able to articulate it well, but I recently saw a good talk on a 
kubernetes CRD status design, just the first few mins where scott is covering 
the tldr might help - https://youtu.be/iNp-fsffIgQ?t=70
   
   >is that representative of the sort of things you don't have a good way to 
poll for?
   
   we wanted to make "ack-to-provisioner" process event driven instead of 
polling, because if we go the polling route, we will have to write custom logic 
for each operator based service, versus implementing something at CR status 
level, which will save us from lot of code maintenance since most of the other 
operators already follow this pattern I think.
   
   >It feels like observedGeneration might send a wrong (or at least 
incomplete?) signal to your provisioner/UI much of the time. Have you thought 
much about those scenarios? Is there maybe something I'm missing?
   
   Yes, we have thought about this, and to handle this, we have a check where 
we only send the ack for success scenarios right now, specifically when a 
condition like this becomes true: 
   `are all the condition status true && is the observedGeneration equal to 
metadata generation && is the observedGeneration value greater than last 
observedGeneration for which we sent an ack` 
   this would take care of scenarios where the instance is created the first 
time and/or if its resized.
   Now, in this above logic, we dont really use `lastTransitionTime`, but I 
added it in the issue, because generally speaking, the time helps in other day 
to day operational activities. 
   
   Apologies if I have gone south of what you actually asked.


-- 
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-17589) First use of PUT/POST request with HttpJdkSolrClient generates error log entry on solr server due to initial HEAD request

[Paul Blanchaert (Jira)]

Paul Blanchaert created SOLR-17589:
--

 Summary: First use of PUT/POST request with HttpJdkSolrClient 
generates error log entry on solr server due to initial HEAD request
 Key: SOLR-17589
 URL: https://issues.apache.org/jira/browse/SOLR-17589
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: clients - java
Affects Versions: 9.7
Reporter: Paul Blanchaert


The first call of the maybeTryHeadRequest of the HttpJdkSolrClient (used in the 
preparePutOrPost) causes an ERROR log entry in the solr server log even while 
the "HEAD" request is considered successful in the client.

The client only performs this request once.

The error on server side is due to the "empty" request: "missing content stream"

2024-12-10 08:31:48 2024-12-10 07:31:48.877 INFO  (qtp1380924218-23-solr-123) 
[c:collection1 s:shard1 r:core_node2 x:collection1_shard1_replica_n1 
t:solr-123] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update 
params={}{} 0 0
2024-12-10 08:31:48 2024-12-10 07:31:48.877 ERROR (qtp1380924218-23-solr-123) 
[c:collection1 s:shard1 r:core_node2 x:collection1_shard1_replica_n1 
t:solr-123] o.a.s.h.RequestHandlerBase Client exception => 
org.apache.solr.common.SolrException: missing content stream
2024-12-10 08:31:48 at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:93)
2024-12-10 08:31:48 org.apache.solr.common.SolrException: missing content stream
2024-12-10 08:31:48 at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:93)
 ~[?:?]
2024-12-10 08:31:48 at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:226)
 ~[?:?]
2024-12-10 08:31:48 at 
org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
2024-12-10 08:31:48 at 
org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890) 
~[?:?]
2024-12-10 08:31:48 at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576) ~[?:?]
2024-12-10 08:31:48 at 
org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251)
 ~[?:?]
2024-12-10 08:31:48 at 
org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:208)
 ~[?:?]
2024-12-10 08:31:48 at 
org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:243)
 ~[?:?]
2024-12-10 08:31:48 at 
org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:213) 
~[?:?]
2024-12-10 08:31:48 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
 ~[?:?]
2024-12-10 08:31:48 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
 ~[?:?]
2024-12-10 08:31:48 at 
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210) 
~[jetty-servlet-10.0.22.jar:10.0.22]



--
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] [Assigned] (SOLR-17578) Remove ZkController internal core supplier

[Pierre Salagnac (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-17578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Salagnac reassigned SOLR-17578:
--

Assignee: Pierre Salagnac

> Remove ZkController internal core supplier
> --
>
> Key: SOLR-17578
> URL: https://issues.apache.org/jira/browse/SOLR-17578
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Pierre Salagnac
>Assignee: Pierre Salagnac
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When reestablishing Zookeeper session after expiration, Solr has to 
> re-register all cores to Zookeeper (join leader election...).
> Currently, code is bloated and iterates over all cores instances just to get 
> the name and metadata (CoreDescriptor).
> Proposal is to remove the core supplier and just call 
> {{CoreContainer.getCoreDescriptors()}} for such iterations. Iteration will be 
> slightly more efficient.



--
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] Adding ObservedGeneration in the CRD [solr-operator]

[via GitHub]

Shashankft9 commented on issue #650:
URL: https://github.com/apache/solr-operator/issues/650#issuecomment-2530742981

   hello @gerlowskija, we use status of `SolrCloud`  CR as source of truth for 
the process of notifying the provisioner system (UI) that "whatever was put in 
the CR" has been "successfully deployed", so that the provisioner system can 
get an ack. 
   Not just Solr, we use the same mechanism for other operator based services 
of database, streaming and more. 
   
   In this case, without `observedGeneration`, its hard for our automation 
running in kubernetes cluster to identify whether the patch done in the 
`SolrCloud` has been successfully deployed in the actual instance or not, and 
so stopping our automation to send an ack signal to the provisioner system.
   Same way, `lastTransitionTime` adds another layer of proof in the status to 
reflect on whats going on at the CR and operator level - I believe this is 
still not implemented in the PR yet, but if you agree on the intention here, we 
can add that as well!
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Re: [PR] upgrade-log4j2-2.24.2 [solr]

[via GitHub]

ppkarwasz commented on PR #2895:
URL: https://github.com/apache/solr/pull/2895#issuecomment-2530882606

   > * 
[jul-to-slf4j](https://github.com/qos-ch/slf4j/blob/v_2.0.16/jul-to-slf4j/LICENSE.txt)
   
   Since you use Log4j Core in your binary distribution, you should consider 
using the [JUL-to-Log4j API 
bridge](https://logging.apache.org/log4j/2.x/log4j-jul.html) instead. The 
artifact has two _modi operandi_:
   
   * A fast bridge, which replace JUL entirely, but requires the setting of the 
`java.util.logging.manager` Java system property in your startup scripts (see 
[Using 
LogManager](https://logging.apache.org/log4j/2.x/log4j-jul.html#bridge-logmanager)).
   * A slower bridge, similar to the one in `jul-to-slf4j`, but it provides 
direct bridging between JUL and Log4j API (without passing through SLF4J). See 
[Using 
Log4jBridgeHandler](https://logging.apache.org/log4j/2.x/log4j-jul.html#bridge-handler).
   
   > * jcl-over-slf4j, this changed from MIT to ASL in 
[repo](https://github.com/qos-ch/slf4j/blob/v_2.0.16/jcl-over-slf4j/LICENSE.txt),
 but is still using the [base 
license](https://github.com/qos-ch/slf4j/blob/v_2.0.16/LICENSE.txt) in 
downloaded package. Not sure which one to use in this case. @janhoy any idea 
how to handle these cases? Prefer ASL?
   
   Since the release of `commons-logging` 1.3.0, `jcl-over-slf4j` (as well as 
`spring-jcl` and `log4j-jcl`) are no longer necessary. We made [a blog post 
about 
it](https://logging.apache.org/blog/2023/12/02/apache-common-logging-1.3.0.html)
 last year.


-- 
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-16390: fix flaky test ClusterPropsAPITest.testClusterPropertyOpsAllGood [solr]

[via GitHub]

epugh commented on code in PR #2901:
URL: https://github.com/apache/solr/pull/2901#discussion_r1878865570


##
solr/core/src/test/org/apache/solr/handler/admin/api/ClusterPropsAPITest.java:
##
@@ -103,10 +109,9 @@ public void testClusterPropertyOpsAllGood() throws 
Exception {
   // List Properties, this time there should be 1
   o = Utils.executeGET(client.getHttpClient(), baseUrlV2ClusterProps, 
Utils.JSONCONSUMER);
   assertNotNull(o);
-  assertEquals(1, ((List) getObjectByPath(o, true, 
"clusterProperties")).size());
-  assertEquals(
-  testClusterProperty,
-  (String) ((List) getObjectByPath(o, true, 
"clusterProperties")).get(0));
+  assertEquals(initCount + 1, ((List) getObjectByPath(o, true, 
"clusterProperties")).size());

Review Comment:
   much nicer!



-- 
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-17589) First use of PUT/POST request with HttpJdkSolrClient generates error log entry on solr server due to initial HEAD request

[Paul Blanchaert (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904634#comment-17904634
 ] 

Paul Blanchaert commented on SOLR-17589:


[~jdyer] 

If we can modify the HEAD request to send an empty json object as payload, the 
problem should be solved...

We can reproduce with curl:

{{curl -X HEAD --location "http://localhost:8983/solr/collection1/update"}}

--> raises error

While

{{curl -X HEAD --location "http://localhost:8983/solr/collection1/update"; \}}
{{    -H "Content-Type: application/json" \}}
{{    -d '{}'}}

--> doesn't raise error

Content-Type should be one of: [application/xml, application/csv, 
application/json, text/json, text/csv, text/xml, application/javabin, 
application/cbor]

Could this bring us closer to a solution?

> First use of PUT/POST request with HttpJdkSolrClient generates error log 
> entry on solr server due to initial HEAD request
> -
>
> Key: SOLR-17589
> URL: https://issues.apache.org/jira/browse/SOLR-17589
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 9.7
>Reporter: Paul Blanchaert
>Priority: Minor
>
> The first call of the maybeTryHeadRequest of the HttpJdkSolrClient (used in 
> the preparePutOrPost) causes an ERROR log entry in the solr server log even 
> while the "HEAD" request is considered successful in the client.
> The client only performs this request once.
> The error on server side is due to the "empty" request: "missing content 
> stream"
> 2024-12-10 08:31:48 2024-12-10 07:31:48.877 INFO  (qtp1380924218-23-solr-123) 
> [c:collection1 s:shard1 r:core_node2 x:collection1_shard1_replica_n1 
> t:solr-123] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update 
> params={}{} 0 0
> 2024-12-10 08:31:48 2024-12-10 07:31:48.877 ERROR (qtp1380924218-23-solr-123) 
> [c:collection1 s:shard1 r:core_node2 x:collection1_shard1_replica_n1 
> t:solr-123] o.a.s.h.RequestHandlerBase Client exception => 
> org.apache.solr.common.SolrException: missing content stream
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:93)
> 2024-12-10 08:31:48 org.apache.solr.common.SolrException: missing content 
> stream
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:93)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:226)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576) ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:208)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:243)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:213) 
> ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>  ~[?:?]
> 2024-12-10 08:31:48 at 
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210) 
> ~[jetty-servlet-10.0.22.jar:10.0.22]



--
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-16390) Cosmetic improvements and migration to JAX-RS (v2 cluster and clusterprop APIs)

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-16390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904636#comment-17904636
 ] 

ASF subversion and git services commented on SOLR-16390:


Commit 34cae92053283ef069f1d5cefa10ea9502a79329 in solr's branch 
refs/heads/branch_9x from Pierre Salagnac
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=34cae920532 ]

SOLR-16390: fix flaky test ClusterPropsAPITest.testClusterPropertyOpsAllGood 
(#2901)

The test fails when SSL in enabled, because of testing framework that
set 'urlScheme' cluster property. This change updates the test to ignore
existing cluster properties.

(cherry picked from commit e105547be5b36994703d3ed0d38413c65f0b8349)


> Cosmetic improvements and migration to JAX-RS (v2 cluster and clusterprop 
> APIs)
> ---
>
> Key: SOLR-16390
> URL: https://issues.apache.org/jira/browse/SOLR-16390
> Project: Solr
>  Issue Type: Sub-task
>  Components: documentation, v2 API
>Affects Versions: main (10.0)
>Reporter: Jason Gerlowski
>Priority: Major
>  Labels: newdev, pull-request-available
>  Time Spent: 4h
>  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.
> This ticket plans to tackle making the changes required for Solr's "Cluster" 
> and "cluster-prop" APIs.  These APIs are described in detail in the 
> spreadsheet linked above, but are summarized in the table below for 
> convenience and easier tracking.
> 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.)
> *Cosmetic Changes and JAX-RS Conversion*
> ||API Name||Original Form||Desired Form||Status||Volunteer||
> |Upsert ClusterProp|POST /api/cluster \{"set-property": \{...\}\}|PUT 
> /api/cluster/properties/propName \{"value": "propVal"\}|Open|N/A|
> |Upsert ClusterProp (Potentially Nested)|POST /api/cluster 
> \{"set-obj-property": \{...\}\}|PUT /api/cluster/properties \{...\}|Open|N/A|
> |Delete ClusterProp|POST /api/cluster \{"set-property": \{"name": "foo", 
> "value": ""\}\}|DELETE /api/cluster/properties/propName|Open|N/A|
> |Delete Single Async Status|DELETE /api/cluster/command-status/123|DELETE 
> /api/cluster/commands/123|Open|N/A|
> |Delete All Async Status|DELETE /api/cluster/command-status|DELETE 
> /api/cluster/commands|Open|N/A|
> |Get Single Async Status|GET /api/cluster/command-status/123|GET 
> /api/cluster/commands/123|Open|N/A|
> |Create rate-limiter|POST /api/cluster/ \{"set-ratelimiter": \{...\}\}|POST 
> /api/cluster/ratelimiter \{...\}|Open|N/A|



--
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-17541: LBSolrClient implementations should agree on 'getClient()' semantics [solr]

[via GitHub]

jdyer1 commented on code in PR #2899:
URL: https://github.com/apache/solr/pull/2899#discussion_r1878873445


##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttp2SolrClient.java:
##
@@ -94,35 +97,74 @@
  *
  * @since solr 8.0
  */
-public class LBHttp2SolrClient extends 
LBSolrClient {
+public class LBHttp2SolrClient> 
extends LBSolrClient {
 
-  protected final C solrClient;
+  private final Map urlToClient;
+  private final Set urlParamNames;
+
+  private final HttpSolrClientBuilderBase solrClientBuilder;
 
   @SuppressWarnings("unchecked")
   private LBHttp2SolrClient(Builder builder) {
 super(Arrays.asList(builder.solrEndpoints));
-this.solrClient = (C) builder.solrClient;
+this.solrClientBuilder = builder.solrClientBuilder;
+
+this.urlToClient = new ConcurrentHashMap<>();
+for (LBSolrClient.Endpoint endpoint : builder.solrEndpoints) {
+  buildClient(endpoint);
+}
+
 this.aliveCheckIntervalMillis = builder.aliveCheckIntervalMillis;
 this.defaultCollection = builder.defaultCollection;
+
+if (builder.solrClientBuilder.urlParamNames == null) {
+  this.urlParamNames = Collections.emptySet();
+} else {
+  this.urlParamNames = 
Collections.unmodifiableSet(builder.solrClientBuilder.urlParamNames);
+}
+  }
+
+  private synchronized HttpSolrClientBase buildClient(Endpoint endpoint) {

Review Comment:
   The `synchronized` keyword was to prevent multiple threads from adding 
clients for the same Base Url.  However, in taking your advice to use 
`computeIfAbsent` this removes the need.



-- 
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-16966: Add a first-class cache for OrdinalMaps [solr]

[via GitHub]

github-actions[bot] commented on PR #1899:
URL: https://github.com/apache/solr/pull/1899#issuecomment-2533260332

   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

Re: [PR] SOLR-?????: make Lucene's BPReorderingMergePolicy configurable in Solr [solr]

[via GitHub]

github-actions[bot] commented on PR #2641:
URL: https://github.com/apache/solr/pull/2641#issuecomment-2533260117

   This PR is now closed due to 60 days of inactivity after being marked as 
stale.  Re-opening this PR is still possible, in which case it will be marked 
as active 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-15152: Export Tool should export regular and nested docs cleanly in .json, .jsonl, and javabin (second take) [solr]

[via GitHub]

github-actions[bot] closed pull request #2636: SOLR-15152: Export Tool should 
export regular and nested docs cleanly in .json, .jsonl, and javabin (second 
take)
URL: https://github.com/apache/solr/pull/2636


-- 
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-?????: make Lucene's BPReorderingMergePolicy configurable in Solr [solr]

[via GitHub]

github-actions[bot] closed pull request #2641: SOLR-?: make Lucene's 
BPReorderingMergePolicy configurable in Solr
URL: https://github.com/apache/solr/pull/2641


-- 
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-15152: Export Tool should export regular and nested docs cleanly in .json, .jsonl, and javabin (second take) [solr]

[via GitHub]

github-actions[bot] commented on PR #2636:
URL: https://github.com/apache/solr/pull/2636#issuecomment-2533260182

   This PR is now closed due to 60 days of inactivity after being marked as 
stale.  Re-opening this PR is still possible, in which case it will be marked 
as active 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-16707: Avoid "Recursive update" ISE in non-async cache `computeIfAbsent()` [solr]

[via GitHub]

github-actions[bot] commented on PR #1481:
URL: https://github.com/apache/solr/pull/1481#issuecomment-2533260382

   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

Re: [PR] SOLR-16162: FilterQuery should implement DocSetProducer [solr]

[via GitHub]

github-actions[bot] commented on PR #814:
URL: https://github.com/apache/solr/pull/814#issuecomment-2533260422

   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

Re: [PR] Enabling test-retry-gradle-plugin [solr]

[via GitHub]

iamsanjay commented on PR #2665:
URL: https://github.com/apache/solr/pull/2665#issuecomment-2533702480

   https://ge.apache.org/s/qcptlo6laqo5g#info 
   The build scan above is associated with branch_9_7, and the retry logic 
seems to have been introduced shortly after the branch cut-off.


-- 
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-17541: LBSolrClient implementations should agree on 'getClient()' semantics [solr]

[via GitHub]

jdyer1 commented on PR #2899:
URL: https://github.com/apache/solr/pull/2899#issuecomment-2532931605

   As a blocker for this PR, I am getting **many** seemingly-unrelated 
solr-core test failures.  For instance, `PostToolTest#testBasicRun`.  
   
   Maybe this is similar to the problem I describe in #2242, in that by sharing 
resources between client and server in a unit test, we get automatic PKI 
authentication, on which the tests depend.  If this speculation is true, this 
would be *merely* a test bug.  
   
   Otherwise, perhaps solr-core needs to be able to share instances of 
`Http2SolrClient` across its internals?  The major change here being callers 
can only pass a `Builder` to `LbHttp2SolrClient` and `CloudHttp2Solrclient` and 
not a pre-built delegate client.  
   
   In either case I do not know how to continue to make progress so any advice 
is appreciated.


-- 
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-17583: Bring back documentation for Adding Custom Expressions [solr]

[via GitHub]

cfeldmann opened a new pull request, #2903:
URL: https://github.com/apache/solr/pull/2903

   https://issues.apache.org/jira/browse/SOLR-17583
   
   # Description
   
   The section for adding Custom Expressions was removed in Solr 8.8. This 
change brings it back.
   
   # Solution
   
   I found the source for the Custom Expressions section in the 8.7 docs and 
copied It to the current streaming-expressions.adoc page. The Expressible 
interface has been moved into the solrj-streaming package since version 8.7 so 
I updated the link to this interface to point to the correct javadoc location.
   
   # Tests
   
   I ran `./gradlew tidy updateLicenses check -x test` and then opened my local 
copy of the Reference Guide.  I verified that I see the new text and that the 
link to the Expressible javadoc is working.
   
   # 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)
   - [x ] I have developed this patch against the `main` branch.
   - [x ] I have run `./gradlew check`.
   - [ ] I have added tests for my changes.
   - [x ] 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-17583) Bring back documentation for Adding Custom Expressions

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-17583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated SOLR-17583:
--
Labels: newdev pull-request-available  (was: newdev)

> Bring back documentation for Adding Custom Expressions
> --
>
> Key: SOLR-17583
> URL: https://issues.apache.org/jira/browse/SOLR-17583
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 9.7
>Reporter: cfeldmann
>Priority: Major
>  Labels: newdev, pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> A change was pushed to do a major revision of the Streaming Expressions guide 
> almost 4 years ago in version 8.8: SOLR-13105 A visual guide to Solr Math 
> Expressions and Streaming Expressions
>  
> In this change, the following section was removed:
>  
> {quote}Adding Custom Expressions
> Creating your own custom expressions can be easily done by implementing the 
> [Expressible|https://lucene.apache.org/solr/8_5_0/solr-solrj/org/apache/solr/client/solrj/io/stream/expr/Expressible.html]
>  interface. To add a custom expression to the list of known mappings for the 
> /stream and /graph handlers, you just need to declare it as a plugin in 
> solrconfig.xml via:
> 
> {quote}
>  
> There was no mention of deprecating the feature or removing this section.  
> Given the massive size of the diff, it looks to be an inadvertent removal.
>  
> The feature works.  There’s no deprecation of this feature mentioned in any 
> of the Solr docs since it was removed from the guide without explanation.  
> The code itself is not deprecated.
>  
> The Config API doc still includes 
> add-expressible/update-expressible/delete-expressible
>  
> Since the feature still works, has not been deprecated and seems to have been 
> accidently removed from the documentation, let's bring this section back.



--
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