[jira] [Created] (SOLR-17364) Vulnerabilities in Solr 8.11.3
Parag Ninawe created SOLR-17364: --- Summary: Vulnerabilities in Solr 8.11.3 Key: SOLR-17364 URL: https://issues.apache.org/jira/browse/SOLR-17364 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: 8.11.3 Reporter: Parag Ninawe Our Vulnerability scans show new vulnerabilities in Solr 8.11.3 |CVE-2022-3171|protobuf-java-3.15.0.jar|HIGH| |CVE-2024-21634|ion-java-1.0.2.jar|HIGH| |CVE-2023-2976|junit4-ant-2.8.1.jar|HIGH| |CVE-2018-19362|htrace-core4-4.1.0-incubating.jar|CRITICAL| -- 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-16198: Introduce tabbed blocks again [solr]
malliaridis commented on code in PR #2550:
URL: https://github.com/apache/solr/pull/2550#discussion_r1670379638
##
solr/solr-ref-guide/ui-src/css/tabs.css:
##
@@ -0,0 +1,103 @@
+.tabs {
Review Comment:
I configured my IDE to put automatically on all files I create license
headers and explicitly removed it here because I saw that the license header
was missing in other files too. A clarification when to put a header would be
great indeed.
--
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-16198: Introduce tabbed blocks again [solr]
HoustonPutman commented on code in PR #2550:
URL: https://github.com/apache/solr/pull/2550#discussion_r1670617661
##
solr/solr-ref-guide/ui-src/css/tabs.css:
##
@@ -0,0 +1,103 @@
+.tabs {
Review Comment:
I helped commit it so I should probably have a better answer, but I have no
idea why they don't have them. If this is a new file include it for now, and we
will worry about the other ones later?
--
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-17349: (adjusted) SolrDocumentFetcher should always skip lazy field loading overhead if documentCache==null [solr]
magibney merged PR #2551: URL: https://github.com/apache/solr/pull/2551 -- 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-17349) SolrDocumentFetcher should always skip lazy field loading overhead if documentCache==null
[ https://issues.apache.org/jira/browse/SOLR-17349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864231#comment-17864231 ] ASF subversion and git services commented on SOLR-17349: Commit 9a86b2102ef28f603a08fa7fdae153e7ae834960 in solr's branch refs/heads/main from Michael Gibney [ https://gitbox.apache.org/repos/asf?p=solr.git;h=9a86b2102ef ] SOLR-17349: (adjusted) SolrDocumentFetcher should always skip lazy field loading overhead if documentCache==null (#2551) * SOLR-17349: (adjusted) SolrDocumentFetcher should always skip lazy field loading overhead if documentCache==null this also reverts the code change from 390c30ff56ad354a6ee55eaae54713dd8ec4cce3, which is obviated by directly making `enableLazyFieldLoading` conditional on presence of `documentCache`. > SolrDocumentFetcher should always skip lazy field loading overhead if > documentCache==null > - > > Key: SOLR-17349 > URL: https://issues.apache.org/jira/browse/SOLR-17349 > Project: Solr > Issue Type: Improvement >Affects Versions: main (10.0), 8.11.3, 9.6.1 >Reporter: Michael Gibney >Assignee: Michael Gibney >Priority: Minor > Fix For: 9.7 > > Time Spent: 0.5h > Remaining Estimate: 0h > > SolrDocumentFetcher currently still adds some overhead for lazy loading of > stored fields, even when there is no documentCache, in which case iiuc lazy > field loading should be irrelevant. > I stumbled across this while looking into a [problem reported on the > solr-users > list|https://lists.apache.org/thread/myd6ckfd61xmdh2087or1to3t3m2flyn]. The > connection to the reported problem is still a bit mysterious (there are > as-yet-unexplained magic numbers involved), but in some cases at least, the > reported performance degradation was quite significant, and the reported > workaround circumstantially supports this change as a possible fix. > I think this change is a positive one regardless; and if it ends up fixing > the reported issue, so much the better! -- 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-10255 Add support for docValues to solr.BinaryField [solr]
mkhludnev commented on code in PR #2536:
URL: https://github.com/apache/solr/pull/2536#discussion_r1670638010
##
solr/core/src/java/org/apache/solr/schema/BinaryField.java:
##
@@ -112,7 +125,31 @@ public IndexableField createField(SchemaField field,
Object val) {
len = buf.length;
}
-return new org.apache.lucene.document.StoredField(field.getName(), buf,
offset, len);
+return new BytesRef(buf, offset, len);
+ }
+
+ @Override
+ public List createFields(SchemaField field, Object val) {
+IndexableField fval = createField(field, val);
+
+if (field.hasDocValues() && !field.multiValued()) {
+ IndexableField docval = new BinaryDocValuesField(field.getName(),
getBytesRef(val));
+
+ // Only create list if we have 2 values...
+ if (fval != null) {
+List fields = new ArrayList<>(2);
+fields.add(fval);
+fields.add(docval);
+return fields;
+ }
+
+ fval = docval;
+}
+return Collections.singletonList(fval);
Review Comment:
May it be simplified as
```
Stream.of(createField(field, val),
(field.hasDocValues() && !field.multiValued()) ? new
BinaryDocValuesField(field.getName(), getBytesRef(val)):null)
.filter(obj -> obj != null)
.collect(Collectors.toList());
```
?
##
solr/core/src/test-files/solr/collection1/conf/bad-schema-unsupported-docValues.xml:
##
Review Comment:
I'm not sure why to bother with random field. Shouldn't we just remove this
file and test, since now we have binary DV?
--
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-17160: Time based tracking of core admin requests with Caffeine cache [solr]
dsmiley commented on PR #2304: URL: https://github.com/apache/solr/pull/2304#issuecomment-2217925207 Perhaps an additional sentence to highlight that this helps collection backup/restore and other operations scale to 100+ shards. -- 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] Added support for timeAllowed time out in HttpShardHandler [solr]
hiteshk25 commented on PR #2493: URL: https://github.com/apache/solr/pull/2493#issuecomment-2218138160 Pining @gus-asf - sorry to bother you -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17195: Add 'minPrefixLength' soft limit [solr]
gerlowskija merged PR #2499: URL: https://github.com/apache/solr/pull/2499 -- 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-17195) Minimum prefix-length soft limit
[ https://issues.apache.org/jira/browse/SOLR-17195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864308#comment-17864308 ] ASF subversion and git services commented on SOLR-17195: Commit 27ef6d58f72e7a9f125fa7fa81ebe48aa7a2e42b in solr's branch refs/heads/main from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=solr.git;h=27ef6d58f72 ] SOLR-17195: Add 'minPrefixLength' soft limit (#2499) Prefix queries have a memory cost that increases in proportion with the number of indexed terms that start with that prefix. This can cause stability problems, especially for short prefixes which can match a large number of indexed-terms. This commit introduces a new solrconfig.xml setting, `minPrefixQueryTermLength`, similar to the existing `maxBooleanClauses`. This setting causes an error to be thrown any time a prefix query is created with a prefix shorter than the configured minumum. The limit is set at '-1' in the default configset, essentially disabling it. But users may change the value in their own configs or use the 'solr.query.minPrefixLength' property as an override. The limit may also be overridden on a per-query basis by providing a 'minPrefixQueryTermLength' local param. > Minimum prefix-length soft limit > > > Key: SOLR-17195 > URL: https://issues.apache.org/jira/browse/SOLR-17195 > Project: Solr > Issue Type: Sub-task > Components: query >Reporter: Jason Gerlowski >Priority: Major > Time Spent: 4h 20m > Remaining Estimate: 0h > > Solr performs a prefix query by rewriting it as a (potentially) large boolean > or terms query, with a clause for each term in the "term dictionary" that > matches the prefix. The shorter the prefix, the more expensive this can be > and the more likely it is to cause performance problems for users. > We should add a configurable soft-limit, of the type described in SOLR-17191, > to prevent users from unknowingly providing very-short-prefixes. > (This may require coordination and buy-in from the Lucene project, depending > on implementation details.) -- 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-17195) Minimum prefix-length soft limit
[ https://issues.apache.org/jira/browse/SOLR-17195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864329#comment-17864329 ] ASF subversion and git services commented on SOLR-17195: Commit e50df5b86164ecec27f6b01d54bd18f2761be91e in solr's branch refs/heads/branch_9x from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=solr.git;h=e50df5b8616 ] SOLR-17195: Add 'minPrefixLength' soft limit (#2499) Prefix queries have a memory cost that increases in proportion with the number of indexed terms that start with that prefix. This can cause stability problems, especially for short prefixes which can match a large number of indexed-terms. This commit introduces a new solrconfig.xml setting, `minPrefixQueryTermLength`, similar to the existing `maxBooleanClauses`. This setting causes an error to be thrown any time a prefix query is created with a prefix shorter than the configured minumum. The limit is set at '-1' in the default configset, essentially disabling it. But users may change the value in their own configs or use the 'solr.query.minPrefixLength' property as an override. The limit may also be overridden on a per-query basis by providing a 'minPrefixQueryTermLength' local param. > Minimum prefix-length soft limit > > > Key: SOLR-17195 > URL: https://issues.apache.org/jira/browse/SOLR-17195 > Project: Solr > Issue Type: Sub-task > Components: query >Reporter: Jason Gerlowski >Priority: Major > Time Spent: 4h 20m > Remaining Estimate: 0h > > Solr performs a prefix query by rewriting it as a (potentially) large boolean > or terms query, with a clause for each term in the "term dictionary" that > matches the prefix. The shorter the prefix, the more expensive this can be > and the more likely it is to cause performance problems for users. > We should add a configurable soft-limit, of the type described in SOLR-17191, > to prevent users from unknowingly providing very-short-prefixes. > (This may require coordination and buy-in from the Lucene project, depending > on implementation details.) -- 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-16198: Introduce tabbed blocks again [solr]
epugh commented on PR #2550: URL: https://github.com/apache/solr/pull/2550#issuecomment-2218757313 It sounds like this pr is good to go, hopefully @HoustonPutman will create the jira for adding missing licenses! We don't normally credit ref guide changes but maybe should with this one since it's improving the tooling. @malliaridis how do you want to be credited? -- 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-10654) Expose Metrics in Prometheus format DIRECTLY from Solr
[
https://issues.apache.org/jira/browse/SOLR-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864416#comment-17864416
]
Chris M. Hostetter commented on SOLR-10654:
---
{{TestPrometheusResponseWriter.testPrometheusOutput}} has failed in 100% of the
jenkins builds that have run it since being added yesterday ... the problem
appears to be some jardcoded assumptions about metric ordering?
{noformat}
org.apache.solr.response.TestPrometheusResponseWriter > testPrometheusOutput
FAILED
org.junit.ComparisonFailure: expected:<... TYPE solr_metrics_j[]vm_buffers
gauge
sol...> but was:<... TYPE solr_metrics_j[etty_dispatches_total counter
solr_metrics_jetty_dispatches_total 0.0
# TYPE solr_metrics_jetty_requests_total counter
solr_metrics_jetty_requests_total{method="active"}
# TYPE solr_metrics_jetty_response_total counter
solr_metrics_jetty_response_total{status="2xx"}
# TYPE solr_metrics_j]vm_buffers gauge
sol...>
at
__randomizedtesting.SeedInfo.seed([76D2036CF55247FD:F7C26E458CF7A80B]:0)
at org.junit.Assert.assertEquals(Assert.java:117)
at org.junit.Assert.assertEquals(Assert.java:146)
at
org.apache.solr.response.TestPrometheusResponseWriter.testPrometheusOutput(TestPrometheusResponseWriter.java:86)
{noformat}
Likewise {{MetricsHandlerTest.testPrometheusMetricsJvm}} has failed 50% of the
jenkins builds that jave run it since being added yesterday ... notably always
on Uwe's jenkins machine, suggesting some hardcoded assumptions about metrics
that may not be true in long running JVMs...
{noformat}
org.apache.solr.handler.admin.MetricsHandlerTest > testPrometheusMetricsJvm
FAILED
java.lang.AssertionError: expected:<0.0> but was:<3604480.0>
at
__randomizedtesting.SeedInfo.seed([5F3548D00F329FF4:577F9BC55C62D284]:0)
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotEquals(Assert.java:835)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:685)
at
org.apache.solr.handler.admin.MetricsHandlerTest.testPrometheusMetricsJvm(MetricsHandlerTest.java:925)
{noformat}
> Expose Metrics in Prometheus format DIRECTLY from Solr
> --
>
> Key: SOLR-10654
> URL: https://issues.apache.org/jira/browse/SOLR-10654
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>Reporter: Keith Laban
>Priority: Major
> Attachments: prometheus_metrics.txt
>
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> Expose metrics via a `wt=prometheus` response type.
> Example scape_config in prometheus.yml:
> {code:java}
> scrape_configs:
> - job_name: 'solr'
> metrics_path: '/solr/admin/metrics'
> params:
> wt: ["prometheus"]
> static_configs:
> - targets: ['localhost:8983']
> {code}
> [Rationale|https://issues.apache.org/jira/browse/SOLR-11795?focusedCommentId=17261423&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17261423]
> for having this despite the "Prometheus Exporter". They have different
> strengths and weaknesses.
--
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-17360) ShardSplitTest 100% failures on main branch
[
https://issues.apache.org/jira/browse/SOLR-17360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864417#comment-17864417
]
ASF subversion and git services commented on SOLR-17360:
Commit e9511d5794cd7b6cb8798d928a3c84ff1a9a1d4f in solr's branch
refs/heads/main from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=e9511d5794c ]
SOLR-17360: Fix test broken by SOLR-17067
> ShardSplitTest 100% failures on main branch
> ---
>
> Key: SOLR-17360
> URL: https://issues.apache.org/jira/browse/SOLR-17360
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> ShardSplitTest is a nightly only testclass that has 4 test methods which have
> recently been failing 100% of the time in jenkins, regardless of seed...
> * testSplitMixedReplicaTypes
> * testSplitStaticIndexReplicationLink
> * testSplitStaticIndexReplication
> * testSplitMixedReplicaTypesLink
>
> ...but AFAICT these failures are not new. IIUC this test has been failing on
> 100% of – the _MAIN_ branch – jenkins builds since ~ Oct/Nov {*}2023{*}!
> (I believe the historical graphs since then just look "sporadic" because it's
> a nightly only test so run's very infrequently and was still (mostly) passing
> on the 9x branch)
>
>
>
> It's trivial to see these failures locally, regardless of seed; or whether
> you run a single test method, or multiple test methods.
> Example...
> {noformat}
> git clean -fd && ./gradlew -p solr/core test -Ptests.nightly=true --tests
> ShardSplitTest.testSplitMixedReplicaTypes{noformat}
>
> The failures are all fairly non-sopecific...
> {noformat}
> > java.util.concurrent.TimeoutException: Timeout waiting to see state
> for collection=testSplitMixedReplicaTypes_rewrite
> :DocCollection(testSplitMixedReplicaTypes_rewrite//collections/testSplitMixedReplicaTypes_rewrite/state.json/18
> )={
> > "pullReplicas":2,
> > "configName":"conf1",
> ...
> > at
> __randomizedtesting.SeedInfo.seed([462B215EC450E717:FEE875FE388B3262]:0)
> > at
> org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1884)
> > at
> org.apache.solr.cloud.api.collections.ShardSplitTest.doSplitMixedReplicaTypes(ShardSplitTest.java:442)
> > at
> org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitMixedReplicaTypes(ShardSplitTest.java:407){noformat}
>
> ...with no errors in the logs indicating when/what might be going wrong.
>
--
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-17067) SolrCloudTestCase activeClusterShape() should only consider active shards
[ https://issues.apache.org/jira/browse/SOLR-17067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864418#comment-17864418 ] ASF subversion and git services commented on SOLR-17067: Commit e9511d5794cd7b6cb8798d928a3c84ff1a9a1d4f in solr's branch refs/heads/main from Chris M. Hostetter [ https://gitbox.apache.org/repos/asf?p=solr.git;h=e9511d5794c ] SOLR-17360: Fix test broken by SOLR-17067 > SolrCloudTestCase activeClusterShape() should only consider active shards > - > > Key: SOLR-17067 > URL: https://issues.apache.org/jira/browse/SOLR-17067 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: main (10.0) >Reporter: Ilan Ginzburg >Assignee: Ilan Ginzburg >Priority: Minor > Fix For: main (10.0) > > Time Spent: 20m > Remaining Estimate: 0h > > Method activeClusterShape() in SolrCloudTestCase counts only active shards > (slices) but counts active replicas on all shards. > For consistency, it should only count active replicas on active shards. -- 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-17360) ShardSplitTest 100% failures on main branch
[
https://issues.apache.org/jira/browse/SOLR-17360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter resolved SOLR-17360.
---
Fix Version/s: main (10.0)
Assignee: Chris M. Hostetter
Resolution: Fixed
> ShardSplitTest 100% failures on main branch
> ---
>
> Key: SOLR-17360
> URL: https://issues.apache.org/jira/browse/SOLR-17360
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: main (10.0)
>
>
> ShardSplitTest is a nightly only testclass that has 4 test methods which have
> recently been failing 100% of the time in jenkins, regardless of seed...
> * testSplitMixedReplicaTypes
> * testSplitStaticIndexReplicationLink
> * testSplitStaticIndexReplication
> * testSplitMixedReplicaTypesLink
>
> ...but AFAICT these failures are not new. IIUC this test has been failing on
> 100% of – the _MAIN_ branch – jenkins builds since ~ Oct/Nov {*}2023{*}!
> (I believe the historical graphs since then just look "sporadic" because it's
> a nightly only test so run's very infrequently and was still (mostly) passing
> on the 9x branch)
>
>
>
> It's trivial to see these failures locally, regardless of seed; or whether
> you run a single test method, or multiple test methods.
> Example...
> {noformat}
> git clean -fd && ./gradlew -p solr/core test -Ptests.nightly=true --tests
> ShardSplitTest.testSplitMixedReplicaTypes{noformat}
>
> The failures are all fairly non-sopecific...
> {noformat}
> > java.util.concurrent.TimeoutException: Timeout waiting to see state
> for collection=testSplitMixedReplicaTypes_rewrite
> :DocCollection(testSplitMixedReplicaTypes_rewrite//collections/testSplitMixedReplicaTypes_rewrite/state.json/18
> )={
> > "pullReplicas":2,
> > "configName":"conf1",
> ...
> > at
> __randomizedtesting.SeedInfo.seed([462B215EC450E717:FEE875FE388B3262]:0)
> > at
> org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1884)
> > at
> org.apache.solr.cloud.api.collections.ShardSplitTest.doSplitMixedReplicaTypes(ShardSplitTest.java:442)
> > at
> org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitMixedReplicaTypes(ShardSplitTest.java:407){noformat}
>
> ...with no errors in the logs indicating when/what might be going wrong.
>
--
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-16291 : Decay function queries gauss,linear,exponential [solr]
github-actions[bot] commented on PR #939: URL: https://github.com/apache/solr/pull/939#issuecomment-2219068808 This PR has had no activity for 60 days and is now labeled as stale. Any new activity or converting it to draft will remove the stale label. To attract more reviewers, please tag people who might be familiar with the code area and/or notify the d...@solr.apache.org mailing list. Thank you for your contribution! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-16198: Introduce tabbed blocks again [solr]
malliaridis commented on PR #2550: URL: https://github.com/apache/solr/pull/2550#issuecomment-2219241785 > We don't normally credit ref guide changes but maybe should with this one since it's improving the tooling. @malliaridis how do you want to be credited? Your kind offer @epugh is more than enough. You don't have to make an exception for this. 😅 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Cross-DC: Get tests passing and checker cleanup. [solr]
markrmiller commented on PR #2541: URL: https://github.com/apache/solr/pull/2541#issuecomment-2219344405 I didn't get to this today, but will respond and test out on windows tomorrow. -- 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
