[jira] [Created] (SOLR-17201) Make Http2SolrClients not experimental
Jan Høydahl created SOLR-17201: -- Summary: Make Http2SolrClients not experimental Key: SOLR-17201 URL: https://issues.apache.org/jira/browse/SOLR-17201 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: SolrJ Reporter: Jan Høydahl Assignee: Jan Høydahl Since their introduction in SOLR-12297 the Http2 (jetty) solr clients have been marked as experimental both in code and in reference guide. This is causing some confusion now that the apache http client is deprecated, see [https://stackoverflow.com/questions/77560198/solrj-confusion-about-clients] We should un-experimental the http2 suite of clients from Solr 9.6 -- 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-17201 Make Http2SolrClients not experimental [solr]
janhoy commented on code in PR #2345:
URL: https://github.com/apache/solr/pull/2345#discussion_r1524517935
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpClientBuilderFactory.java:
##
@@ -19,10 +19,7 @@
import java.io.Closeable;
/**
- * Factory interface for configuring {@linkplain SolrHttpClientBuilder}. This
relies on the internal
- * HttpClient implementation and is subject to change.
- *
- * @lucene.experimental
+ * Factory interface for configuring {@linkplain SolrHttpClientBuilder}.
Review Comment:
I'm confused by this class claiming to be a factory for Apache HTTP client,
but also has a `setup` method with `Http2SolrClient` as argument. Can anyone
clarify?
--
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-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827148#comment-17827148 ] ASF subversion and git services commented on SOLR-599: -- Commit c8c600116ed4921afc43ee85f6caacf65c4b1d8d in solr's branch refs/heads/main from James Dyer [ https://gitbox.apache.org/repos/asf?p=solr.git;h=c8c600116ed ] SOLR-599: Better thread clean-up in unit tests (#2259) > Lightweight SolrJ client > > > Key: SOLR-599 > URL: https://issues.apache.org/jira/browse/SOLR-599 > Project: Solr > Issue Type: Improvement > Components: clients - java, SolrJ >Reporter: Shalin Shekhar Mangar >Assignee: James Dyer >Priority: Minor > Fix For: main (10.0), 9.6.0 > > Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, > SOLR-599.patch > > Time Spent: 8.5h > Remaining Estimate: 0h > > SolrJ provides a SolrServer implementation backed by commons-httpclient which > introduces many dependency jars (commons-codec, commons-io and > commons-logging). Apart from that SolrJ also uses StAX API for XML parsing > which introduces dependencies like stax-api, stax and stax-utils. > This enhancement will add a SolrServer implementation backed by > -java.net.HttpUrlConnection- java.net.http.HttpClient and will use > BinaryResponseParser as the default response parser. Using this basic > implementation out of the box would require no dependencies on either > commons-httpclient or StAX. The only dependency would be on solr-commons > making this a very lightweight and distribution friendly Java client for Solr. > - > h3. See PR [#2259|https://github.com/apache/solr/pull/2259] for details on > the actual resolution. -- 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-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827151#comment-17827151 ] ASF subversion and git services commented on SOLR-599: -- Commit 7eb38d5e7ddd31cae49f768c19cc0e13a5e19247 in solr's branch refs/heads/branch_9x from James Dyer [ https://gitbox.apache.org/repos/asf?p=solr.git;h=7eb38d5e7dd ] SOLR-599: Better thread clean-up in unit tests (#2259) > Lightweight SolrJ client > > > Key: SOLR-599 > URL: https://issues.apache.org/jira/browse/SOLR-599 > Project: Solr > Issue Type: Improvement > Components: clients - java, SolrJ >Reporter: Shalin Shekhar Mangar >Assignee: James Dyer >Priority: Minor > Fix For: main (10.0), 9.6.0 > > Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, > SOLR-599.patch > > Time Spent: 8.5h > Remaining Estimate: 0h > > SolrJ provides a SolrServer implementation backed by commons-httpclient which > introduces many dependency jars (commons-codec, commons-io and > commons-logging). Apart from that SolrJ also uses StAX API for XML parsing > which introduces dependencies like stax-api, stax and stax-utils. > This enhancement will add a SolrServer implementation backed by > -java.net.HttpUrlConnection- java.net.http.HttpClient and will use > BinaryResponseParser as the default response parser. Using this basic > implementation out of the box would require no dependencies on either > commons-httpclient or StAX. The only dependency would be on solr-commons > making this a very lightweight and distribution friendly Java client for Solr. > - > h3. See PR [#2259|https://github.com/apache/solr/pull/2259] for details on > the actual resolution. -- 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-17202) Change SolrJ maven coordinates (10.x)
Jan Høydahl created SOLR-17202:
--
Summary: Change SolrJ maven coordinates (10.x)
Key: SOLR-17202
URL: https://issues.apache.org/jira/browse/SOLR-17202
Project: Solr
Issue Type: Sub-task
Components: SolrJ
Reporter: Jan Høydahl
Change maven coordinates to {{org.apache.solr.solrj}}
--
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-599) Lightweight SolrJ client
[
https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827171#comment-17827171
]
Jan Høydahl commented on SOLR-599:
--
{quote}I think so, but we might need a Load Balancing Jdk Client first? Also,
doesn't CloudSolrClient pull in zookeeper as a client-side dependency? My
thinking here is users that use CSC are perhaps not too concerned with
transitive dependencies?
{quote}
Yes, we need also a LB client. CloudSolrClient does not depend on zookeeper, it
was already de-coupled in 9.0, we can now use HttpClusterStateProvider.
So a CloudSolrClient could be useful also for the minimal case with pure http.
Let's make some JIRAs for the LB and Cloud equivalents.
> Lightweight SolrJ client
>
>
> Key: SOLR-599
> URL: https://issues.apache.org/jira/browse/SOLR-599
> Project: Solr
> Issue Type: Improvement
> Components: clients - java, SolrJ
>Reporter: Shalin Shekhar Mangar
>Assignee: James Dyer
>Priority: Minor
> Fix For: main (10.0), 9.6.0
>
> Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch,
> SOLR-599.patch
>
> Time Spent: 8.5h
> Remaining Estimate: 0h
>
> SolrJ provides a SolrServer implementation backed by commons-httpclient which
> introduces many dependency jars (commons-codec, commons-io and
> commons-logging). Apart from that SolrJ also uses StAX API for XML parsing
> which introduces dependencies like stax-api, stax and stax-utils.
> This enhancement will add a SolrServer implementation backed by
> -java.net.HttpUrlConnection- java.net.http.HttpClient and will use
> BinaryResponseParser as the default response parser. Using this basic
> implementation out of the box would require no dependencies on either
> commons-httpclient or StAX. The only dependency would be on solr-commons
> making this a very lightweight and distribution friendly Java client for Solr.
> -
> h3. See PR [#2259|https://github.com/apache/solr/pull/2259] for details on
> the actual resolution.
--
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-17106) LBSolrClient: Make it configurable to remove zombie ping checks
[
https://issues.apache.org/jira/browse/SOLR-17106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827178#comment-17827178
]
Aparna Suresh commented on SOLR-17106:
--
Hi [~hossman] ,
I made the changes you requested. I opted not to declare
{{aliveCheckSkipIters}} and {{aliveCheckQuery}} as final variables in the
Builder classes of {{LBHttp2SolrClient}} and {{{}LBHttpSolrClient{}}}. These
variables are designed to be overridden using the setter methods within the
Builder. The overrides are being tested in TestLBHttp2SolrClient.
Please let me know. Thank you!
> LBSolrClient: Make it configurable to remove zombie ping checks
> ---
>
> Key: SOLR-17106
> URL: https://issues.apache.org/jira/browse/SOLR-17106
> Project: Solr
> Issue Type: Improvement
>Reporter: Aparna Suresh
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Following discussion from a dev list discussion here:
> [https://lists.apache.org/thread/f0zfmpg0t48xrtppyfsmfc5ltzsq2qqh]
> The issue involves scalability challenges in SolrJ's *LBSolrClient* when a
> pod with numerous cores experiences connectivity problems. The "zombie"
> tracking mechanism, operating on a core basis, becomes a bottleneck during
> distributed search on a massive multi shard collection. Threads attempting to
> reach unhealthy cores contribute to a high computational load, causing
> performance issues.
> As suggested by Chris Hostetter: LBSolrClient could be configured to disable
> zombie "ping" checks, but retain zombie tracking. Once a replica/endpoint is
> identified as a zombie, it could be held in zombie jail for X seconds, before
> being released - hoping that by this timeframe ZK would be updated to mark
> this endpoint DOWN or the pod is back up and CloudSolrClient would avoid
> querying it. In any event, only 1 failed query would be needed to send the
> server back to zombie jail.
>
> There are benefits in doing this change:
> * Eliminate the zombie ping requests, which would otherwise overload pod(s)
> coming up after a restart
> * Avoid memory leaks, in case a node/replica goes away permanently, but it
> stays as zombie forever, with a background thread in LBSolrClient constantly
> pinging it
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15730) Modularize SolrJ
[ https://issues.apache.org/jira/browse/SOLR-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827196#comment-17827196 ] David Smiley commented on SOLR-15730: - SolrJ gained Jackson recently, related to the new v2 API / OpenApi work :(. Ahh well. > Modularize SolrJ > > > Key: SOLR-15730 > URL: https://issues.apache.org/jira/browse/SOLR-15730 > Project: Solr > Issue Type: Task > Components: SolrJ >Reporter: Jan Høydahl >Priority: Major > Attachments: Skjermbilde 2021-10-28 kl. 15.38.40.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Umbrella issue for breaking up SolrJ into a slim solrj-core with minimal > dependencies as well as solrj-zk, solrj-streaming, solrj-jdbc etc as needed. > We can move relevant other JIRAs as sub-tasks to this one to keep everything > together. -- 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-16505: Switch UpdateShardHandler.getRecoveryOnlyHttpClient to Jetty HTTP2 [solr]
dsmiley commented on code in PR #2276:
URL: https://github.com/apache/solr/pull/2276#discussion_r1525398141
##
solr/core/src/java/org/apache/solr/handler/IndexFetcher.java:
##
@@ -261,22 +260,23 @@ public String getMessage() {
}
}
- private static HttpClient createHttpClient(
- SolrCore core,
- String httpBasicAuthUser,
- String httpBasicAuthPassword,
- boolean useCompression) {
+ private Http2SolrClient createHttpClient(
+ SolrCore core, String httpBasicAuthUser, String httpBasicAuthPassword,
String leaderBaseUrl) {
final ModifiableSolrParams httpClientParams = new ModifiableSolrParams();
Review Comment:
I did some digging here. IndexFetcher can be configured with
httpBasicAuthUser and httpBasicAuthPassword in its solrconfig.xml based
configuration however this isn't document, and seems rather ancient / legacy to
me. Let's just drop this. Not sure it's even worth mentioning in upgrade
notes.
--
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-16505: Switch UpdateShardHandler.getRecoveryOnlyHttpClient to Jetty HTTP2 [solr]
dsmiley commented on PR #2276: URL: https://github.com/apache/solr/pull/2276#issuecomment-1998300785 Glad that you did the compression testing manually! I think at this point the PR just needs a few method/field renames to reflect to not confuse a SolrClient with an HttpClient. And there's the IndexFetcher basic authentication that's obsolete. -- 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-16403) SPLITSHARD should delete the parent shard after success
[ https://issues.apache.org/jira/browse/SOLR-16403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827227#comment-17827227 ] ASF subversion and git services commented on SOLR-16403: Commit ca58f1aa90b351b69b0ec4184adbaaca03978573 in solr's branch refs/heads/main from pjmcarthur [ https://gitbox.apache.org/repos/asf?p=solr.git;h=ca58f1aa90b ] SOLR-16403: ClusterSingleton to remove inactive Shards (#1926) ClusterSingleton that periodically removes state=INACTIVE shards. These occur from shard splits. Co-authored-by: Paul McArthur > SPLITSHARD should delete the parent shard after success > --- > > Key: SOLR-16403 > URL: https://issues.apache.org/jira/browse/SOLR-16403 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > When a shard is split into two sub-shards, the parent (the original) will > remain in an "INACTIVE" state. It's up to the user/admin to devise some > clean-up process. I propose that SplitShardCmd clean up after itself. It's > not clear why it didn't do this all along. -- 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-16403: Cluster Singleton to remove inactive Shards [solr]
dsmiley merged PR #1926: URL: https://github.com/apache/solr/pull/1926 -- 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-16403) SPLITSHARD should delete the parent shard after success
[ https://issues.apache.org/jira/browse/SOLR-16403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827236#comment-17827236 ] David Smiley commented on SOLR-16403: - Whoops; I don't think that PR should be using this JIRA reference. I think this JIRA remains valid. I'll create another and edit CHANGES.txt. Too bad got commits are forever :-| > SPLITSHARD should delete the parent shard after success > --- > > Key: SOLR-16403 > URL: https://issues.apache.org/jira/browse/SOLR-16403 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > When a shard is split into two sub-shards, the parent (the original) will > remain in an "INACTIVE" state. It's up to the user/admin to devise some > clean-up process. I propose that SplitShardCmd clean up after itself. It's > not clear why it didn't do this all along. -- 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-16403) SPLITSHARD should delete the parent shard after success
[ https://issues.apache.org/jira/browse/SOLR-16403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827237#comment-17827237 ] David Smiley commented on SOLR-16403: - On second thought; I'm going to retitle this, re-description this, and keep the original idea under a horizontal line > SPLITSHARD should delete the parent shard after success > --- > > Key: SOLR-16403 > URL: https://issues.apache.org/jira/browse/SOLR-16403 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > When a shard is split into two sub-shards, the parent (the original) will > remain in an "INACTIVE" state. It's up to the user/admin to devise some > clean-up process. I propose that SplitShardCmd clean up after itself. It's > not clear why it didn't do this all along. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16403) INACTIVE shards should be deleted periodically
[ https://issues.apache.org/jira/browse/SOLR-16403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-16403: Summary: INACTIVE shards should be deleted periodically (was: SPLITSHARD should delete the parent shard after success) > INACTIVE shards should be deleted periodically > -- > > Key: SOLR-16403 > URL: https://issues.apache.org/jira/browse/SOLR-16403 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > When a shard is split into two sub-shards, the parent (the original) will > remain in an "INACTIVE" state. It's up to the user/admin to devise some > clean-up process. I propose that SplitShardCmd clean up after itself. It's > not clear why it didn't do this all along. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16403) INACTIVE shards should be deleted periodically
[ https://issues.apache.org/jira/browse/SOLR-16403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-16403: Description: Have a periodic mechanism to delete state=INACTIVE shards. The implementation is a ClusterSingleton. *Original title:* SPLITSHARD should delete the parent shard after success *Original description:* When a shard is split into two sub-shards, the parent (the original) will remain in an "INACTIVE" state. It's up to the user/admin to devise some clean-up process. I propose that SplitShardCmd clean up after itself. It's not clear why it didn't do this all along. was: Have a periodic mechanism to delete state=INACTIVE shards. The implementation is a ClusterSingleton. *Original title:* SPLITSHARD should delete the parent shard after success *Original description: * When a shard is split into two sub-shards, the parent (the original) will remain in an "INACTIVE" state. It's up to the user/admin to devise some clean-up process. I propose that SplitShardCmd clean up after itself. It's not clear why it didn't do this all along. > INACTIVE shards should be deleted periodically > -- > > Key: SOLR-16403 > URL: https://issues.apache.org/jira/browse/SOLR-16403 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Have a periodic mechanism to delete state=INACTIVE shards. The > implementation is a ClusterSingleton. > > *Original title:* SPLITSHARD should delete the parent shard after success > *Original description:* > When a shard is split into two sub-shards, the parent (the original) will > remain in an "INACTIVE" state. It's up to the user/admin to devise some > clean-up process. I propose that SplitShardCmd clean up after itself. It's > not clear why it didn't do this all along. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16403) INACTIVE shards should be deleted periodically
[ https://issues.apache.org/jira/browse/SOLR-16403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-16403: Description: Have a periodic mechanism to delete state=INACTIVE shards. The implementation is a ClusterSingleton. *Original title:* SPLITSHARD should delete the parent shard after success *Original description: * When a shard is split into two sub-shards, the parent (the original) will remain in an "INACTIVE" state. It's up to the user/admin to devise some clean-up process. I propose that SplitShardCmd clean up after itself. It's not clear why it didn't do this all along. was:When a shard is split into two sub-shards, the parent (the original) will remain in an "INACTIVE" state. It's up to the user/admin to devise some clean-up process. I propose that SplitShardCmd clean up after itself. It's not clear why it didn't do this all along. > INACTIVE shards should be deleted periodically > -- > > Key: SOLR-16403 > URL: https://issues.apache.org/jira/browse/SOLR-16403 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Have a periodic mechanism to delete state=INACTIVE shards. The > implementation is a ClusterSingleton. > > *Original title:* SPLITSHARD should delete the parent shard after success > *Original description: * > When a shard is split into two sub-shards, the parent (the original) will > remain in an "INACTIVE" state. It's up to the user/admin to devise some > clean-up process. I propose that SplitShardCmd clean up after itself. It's > not clear why it didn't do this all along. -- 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] Update dependency com.fasterxml.jackson:jackson-bom to v2.16.2 [solr]
solrbot opened a new pull request, #2346: URL: https://github.com/apache/solr/pull/2346 This PR contains the following updates: | Package | Type | Update | Change | Pending | |---|---|---|---|---| | [com.fasterxml.jackson:jackson-bom](https://togithub.com/FasterXML/jackson-bom) | dependencies | patch | `2.16.1` -> `2.16.2` | `2.17.0` | --- ### Configuration 📅 **Schedule**: Branch creation - "* * * * *" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://togithub.com/solrbot/renovate-github-action) -- 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] Tests: avoid NPE in JettySolrRunner lifeCycleStopped [solr]
dsmiley merged PR #2337: URL: https://github.com/apache/solr/pull/2337 -- 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-16824: Adopt Linux Command line tool pattern of -- for long option commands [solr]
madrob commented on code in PR #1768: URL: https://github.com/apache/solr/pull/1768#discussion_r1525478638 ## solr/bin/solr.cmd: ## @@ -544,14 +544,13 @@ IF "%1"=="-t" goto set_solr_data_dir IF "%1"=="-solr.home" goto set_solr_home_dir IF "%1"=="-e" goto set_example IF "%1"=="-example" goto set_example -IF "%1"=="-host" goto set_host +IF "%1"=="--host" goto set_host IF "%1"=="-m" goto set_memory IF "%1"=="-memory" goto set_memory IF "%1"=="-p" goto set_port IF "%1"=="-port" goto set_port IF "%1"=="-z" goto set_zookeeper -IF "%1"=="-zkhost" goto set_zookeeper -IF "%1"=="-zkHost" goto set_zookeeper +IF "%1"=="-zk-host" goto set_zookeeper Review Comment: double-dash? -- 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-17203) CPU not calculated correctly in ThreadCpuTimer
Gus Heck created SOLR-17203: --- Summary: CPU not calculated correctly in ThreadCpuTimer Key: SOLR-17203 URL: https://issues.apache.org/jira/browse/SOLR-17203 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Query Limits Affects Versions: main (10.0), 9.6.0 Reporter: Gus Heck Assignee: Gus Heck Naming is hard, and the initial implementation seems to have stumbled on a method naming confusion with the effect that it was only possible to hit a cpu time out shortly after a new thread is created (which is true when the tests run, and thus the test was passing). Essentially it was grabbing an elapsed time for the timer and, treating it as the total time for the thread. Fixed locally, will submit PR soon... -- 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-17203 fix calculation for CpuAllowedLimit [solr]
gus-asf opened a new pull request, #2347: URL: https://github.com/apache/solr/pull/2347 https://issues.apache.org/jira/browse/SOLR-17203 -- 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-599 New Solr Client Using Java 11+ java.net.http.HttpClient [solr]
dsmiley commented on PR #2259: URL: https://github.com/apache/solr/pull/2259#issuecomment-1998729601 @jdyer1 Lets use a PR to collaborate on workaroundToReleaseThreads_noClosableUntilJava21. Getting all threads and interrupting each is a hack I'd like to try and avoid. I don't recall any test doing that despite us having a crazy number of tests. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-599 New Solr Client Using Java 11+ java.net.http.HttpClient [solr]
dsmiley commented on PR #2259: URL: https://github.com/apache/solr/pull/2259#issuecomment-1998742427 Instead of simply interrupting the threads, shouldn't we also join on them? Should that be in an AfterClass -- is it a problem between each test? note: you don't need to gather a Set to then iterate; you can call `forEach` on the stream to do whatever you want to do. I don't think using a Set (for uniqueness) is necessary here either. What is the GC accomplishing? I was looking again at all those test overrides that call super. I removed them locally and I was able to run at the CLI and IntelliJ and it ran all the intherited tests. This pattern is done elsewhere like SolrExampleTests -- 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-16403) INACTIVE shards should be deleted periodically
[ https://issues.apache.org/jira/browse/SOLR-16403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827314#comment-17827314 ] ASF subversion and git services commented on SOLR-16403: Commit 4098d6ae3e298efdfa219d5a2629d69f60c5aff9 in solr's branch refs/heads/branch_9x from pjmcarthur [ https://gitbox.apache.org/repos/asf?p=solr.git;h=4098d6ae3e2 ] SOLR-16403: ClusterSingleton to remove inactive Shards (#1926) ClusterSingleton that periodically removes state=INACTIVE shards. These occur from shard splits. Co-authored-by: Paul McArthur (cherry picked from commit ca58f1aa90b351b69b0ec4184adbaaca03978573) > INACTIVE shards should be deleted periodically > -- > > Key: SOLR-16403 > URL: https://issues.apache.org/jira/browse/SOLR-16403 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Have a periodic mechanism to delete state=INACTIVE shards. The > implementation is a ClusterSingleton. > > *Original title:* SPLITSHARD should delete the parent shard after success > *Original description:* > When a shard is split into two sub-shards, the parent (the original) will > remain in an "INACTIVE" state. It's up to the user/admin to devise some > clean-up process. I propose that SplitShardCmd clean up after itself. It's > not clear why it didn't do this all along. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16403) INACTIVE shards should be deleted periodically
[ https://issues.apache.org/jira/browse/SOLR-16403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-16403. - Fix Version/s: 9.6.0 Resolution: Fixed > INACTIVE shards should be deleted periodically > -- > > Key: SOLR-16403 > URL: https://issues.apache.org/jira/browse/SOLR-16403 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Priority: Major > Fix For: 9.6.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Have a periodic mechanism to delete state=INACTIVE shards. The > implementation is a ClusterSingleton. > > *Original title:* SPLITSHARD should delete the parent shard after success > *Original description:* > When a shard is split into two sub-shards, the parent (the original) will > remain in an "INACTIVE" state. It's up to the user/admin to devise some > clean-up process. I propose that SplitShardCmd clean up after itself. It's > not clear why it didn't do this all along. -- 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
