[GitHub] [solr] noblepaul opened a new pull request, #1962: Coordinator node does not have correct collection tagged for TracingSpan

2023-09-27 Thread via GitHub 


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

   (no comment)


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

[GitHub] [solr] stillalex commented on pull request #1958: [WIP] SOLR-16985 Upgrade Lucene to 9.8.0

2023-09-27 Thread via GitHub 


stillalex commented on PR #1958:
URL: https://github.com/apache/solr/pull/1958#issuecomment-1738339806

   another set of failures, related to vector search
   
   `
 - 
org.apache.solr.search.neural.KnnQParserTest.highDimensionFloatVectorField_shouldSearchOnThatField
 (:solr:core)
   Test output: 
/Users/alexdeparvu/git/solr/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.search.neural.KnnQParserTest.txt
   Reproduce with: gradlew :solr:core:test --tests 
"org.apache.solr.search.neural.KnnQParserTest.highDimensionFloatVectorField_shouldSearchOnThatField"
 -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC 
-XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m" 
-Ptests.seed=293C1EA1098E2343 -Ptests.file.encoding=US-ASCII
   
 - 
org.apache.solr.search.neural.KnnQParserTest.highDimensionByteVectorField_shouldSearchOnThatField
 (:solr:core)
   Test output: 
/Users/alexdeparvu/git/solr/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.search.neural.KnnQParserTest.txt
   Reproduce with: gradlew :solr:core:test --tests 
"org.apache.solr.search.neural.KnnQParserTest.highDimensionByteVectorField_shouldSearchOnThatField"
 -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC 
-XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m" 
-Ptests.seed=293C1EA1098E2343 -Ptests.file.encoding=US-ASCII
   
 - 
org.apache.solr.schema.DenseVectorFieldTest.indexing_highDimensionalityVectorDocument_shouldBeIndexed
 (:solr:core)
   Test output: 
/Users/alexdeparvu/git/solr/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.schema.DenseVectorFieldTest.txt
   Reproduce with: gradlew :solr:core:test --tests 
"org.apache.solr.schema.DenseVectorFieldTest.indexing_highDimensionalityVectorDocument_shouldBeIndexed"
 -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC 
-XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m" 
-Ptests.seed=293C1EA1098E2343 -Ptests.file.encoding=US-ASCII
   ```


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

[GitHub] [solr] magibney commented on pull request #1899: SOLR-16966: Add a first-class cache for OrdinalMaps

2023-09-27 Thread via GitHub 


magibney commented on PR #1899:
URL: https://github.com/apache/solr/pull/1899#issuecomment-1738322438

   The last three commits (through  b8124677d7c88b903b5f3c4fd24ca8a54596d215) 
introduce a subtle but substantial change that abstracts all the "metadata 
wrapper" accounting so that application code (SolrIndexSearcher, other users of 
caches) know nothing about any potential metadata wrappers around cache value 
entries.
   
   The cleanest place to do this is from the regenerator; I've added `wrap()` 
and `unwrap()` methods to `CacheRegenerator`, with a default passthrough 
implementation. Regenerators that require value-entry metadata accounting (such 
as access timestamp, individual entry hit count, etc.) may override `wrap()` to 
return a simple `SolrCache` view of an underlying `SolrCache>` cache. It is the _raw_ cache (unwrapped) that is 
autowarmed, providing the regenerator with the information it needs to make 
warming decisions, etc. But it is the _wrapped_ cache that is presented for all 
normal cache interactions.
   
   This approach works equally well for implementing more nuanced cache metrics 
(histograms, dumping cache contents, etc.). The overall approach is described 
in the [javadocs 
here](https://github.com/apache/solr/blob/b8124677d7c88b903b5f3c4fd24ca8a54596d215/solr/core/src/java/org/apache/solr/search/MetaCacheRegenerator.java#L36-L62).
 It should be quite trivial to implement regenerators that  implement custom 
metrics.


-- 
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] [Resolved] (SOLR-16992) Non-reproducible StreamingTest failures -- suggests CloudSolrStream concurency race condition

2023-09-27 Thread Alex Deparvu (Jira) 


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

Alex Deparvu resolved SOLR-16992.
-
Fix Version/s: 9.4
   Resolution: Fixed

thanks [~hossman] for the continued review! PR was merged and backported

> Non-reproducible StreamingTest failures -- suggests CloudSolrStream 
> concurency race condition
> -
>
> Key: SOLR-16992
> URL: https://issues.apache.org/jira/browse/SOLR-16992
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Chris M. Hostetter
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 9.4
>
> Attachments: 
> OUTPUT-org.apache.solr.client.solrj.io.stream.StreamingTest.txt, 
> thetaphi_solr_Solr-main-Linux_14679.log.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Roughly 3% of all jenkins jobs that run {{StreamingTest}} wind up having 
> suite level failures.
> These failures have historically taken the form of 
> {{com.carrotsearch.randomizedtesting.ThreadLeakError}} and the leaked threads 
> all have names like
> {{"h2sc-718-thread-2"}} indicating that they come from the internal 
> {{ExecutorService}} of an {{{}Http2SolrClient{}}}.
> In my experience, the seeds from these failures have never reproduced - 
> suggesting that the problem is related to concurrency.
> SOLR-16983 restored the (correct) use of {{ObjectReleaseTracker}} which in 
> theory should help pinpoint where {{Http2SolrClient}} instances might not be 
> getting closed (by causing {{ObjectReleaseTracker}} to fail with stacktraces 
> of when/where any unclosed instances were created - ie: which test method)
> In practice, I have managed to force one failure from {{StreamingTest}} since 
> the SOLR-16983 changes (logs to be attached soon) - but it still didn't 
> indicate any leaked/unclosed {{Http2SolrClient}} instances. What it instead 
> indicated was a _single_ unclosed {{InputStream}} instance related to 
> {{Http2SolrClient}} connections (SOLR-16983 also added better tracking of 
> this) coming from {{StreamingTest.testExceptionStream}} - a test method that 
> opens _five_ very similar {{ExceptionStream}} instances, wrapping 
> {{CloudSolrStream}} instance, which expect to trigger server side errors.
> By it's very design, {{ExceptionStream}} catches & records any exceptions 
> from the stream it wraps, so even in the event of these "expected" server 
> side errors, {{ExceptionStream.close()}} should still be correctly getting 
> called (and propagating down to the {{CloudStream}} it wraps).
> I believe the underlying problem has to do with a concurrency race condition 
> between the call to {{CloudStream.close()}} and the {{ExecutorService}} used 
> internally by {{CloudSolrStream.openStreams()}} (details to follow)



--
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-16992) Non-reproducible StreamingTest failures -- suggests CloudSolrStream concurency race condition

2023-09-27 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on SOLR-16992:


Commit 12b7579573fb7598be3deca8498249c5f00eb821 in solr's branch 
refs/heads/branch_9x from Alex Deparvu
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=12b7579573f ]

SOLR-16992 Non-reproducible StreamingTest failures (#1955)

-- suggests CloudSolrStream concurency race condition

(cherry picked from commit f0fcd300c896b858ae83235ecdb0a109eaea5cea)


> Non-reproducible StreamingTest failures -- suggests CloudSolrStream 
> concurency race condition
> -
>
> Key: SOLR-16992
> URL: https://issues.apache.org/jira/browse/SOLR-16992
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Chris M. Hostetter
>Assignee: Alex Deparvu
>Priority: Major
> Attachments: 
> OUTPUT-org.apache.solr.client.solrj.io.stream.StreamingTest.txt, 
> thetaphi_solr_Solr-main-Linux_14679.log.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Roughly 3% of all jenkins jobs that run {{StreamingTest}} wind up having 
> suite level failures.
> These failures have historically taken the form of 
> {{com.carrotsearch.randomizedtesting.ThreadLeakError}} and the leaked threads 
> all have names like
> {{"h2sc-718-thread-2"}} indicating that they come from the internal 
> {{ExecutorService}} of an {{{}Http2SolrClient{}}}.
> In my experience, the seeds from these failures have never reproduced - 
> suggesting that the problem is related to concurrency.
> SOLR-16983 restored the (correct) use of {{ObjectReleaseTracker}} which in 
> theory should help pinpoint where {{Http2SolrClient}} instances might not be 
> getting closed (by causing {{ObjectReleaseTracker}} to fail with stacktraces 
> of when/where any unclosed instances were created - ie: which test method)
> In practice, I have managed to force one failure from {{StreamingTest}} since 
> the SOLR-16983 changes (logs to be attached soon) - but it still didn't 
> indicate any leaked/unclosed {{Http2SolrClient}} instances. What it instead 
> indicated was a _single_ unclosed {{InputStream}} instance related to 
> {{Http2SolrClient}} connections (SOLR-16983 also added better tracking of 
> this) coming from {{StreamingTest.testExceptionStream}} - a test method that 
> opens _five_ very similar {{ExceptionStream}} instances, wrapping 
> {{CloudSolrStream}} instance, which expect to trigger server side errors.
> By it's very design, {{ExceptionStream}} catches & records any exceptions 
> from the stream it wraps, so even in the event of these "expected" server 
> side errors, {{ExceptionStream.close()}} should still be correctly getting 
> called (and propagating down to the {{CloudStream}} it wraps).
> I believe the underlying problem has to do with a concurrency race condition 
> between the call to {{CloudStream.close()}} and the {{ExecutorService}} used 
> internally by {{CloudSolrStream.openStreams()}} (details to follow)



--
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-16992) Non-reproducible StreamingTest failures -- suggests CloudSolrStream concurency race condition

2023-09-27 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on SOLR-16992:


Commit f0fcd300c896b858ae83235ecdb0a109eaea5cea in solr's branch 
refs/heads/main from Alex Deparvu
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=f0fcd300c89 ]

SOLR-16992 Non-reproducible StreamingTest failures (#1955)

-- suggests CloudSolrStream concurency race condition

> Non-reproducible StreamingTest failures -- suggests CloudSolrStream 
> concurency race condition
> -
>
> Key: SOLR-16992
> URL: https://issues.apache.org/jira/browse/SOLR-16992
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Chris M. Hostetter
>Assignee: Alex Deparvu
>Priority: Major
> Attachments: 
> OUTPUT-org.apache.solr.client.solrj.io.stream.StreamingTest.txt, 
> thetaphi_solr_Solr-main-Linux_14679.log.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Roughly 3% of all jenkins jobs that run {{StreamingTest}} wind up having 
> suite level failures.
> These failures have historically taken the form of 
> {{com.carrotsearch.randomizedtesting.ThreadLeakError}} and the leaked threads 
> all have names like
> {{"h2sc-718-thread-2"}} indicating that they come from the internal 
> {{ExecutorService}} of an {{{}Http2SolrClient{}}}.
> In my experience, the seeds from these failures have never reproduced - 
> suggesting that the problem is related to concurrency.
> SOLR-16983 restored the (correct) use of {{ObjectReleaseTracker}} which in 
> theory should help pinpoint where {{Http2SolrClient}} instances might not be 
> getting closed (by causing {{ObjectReleaseTracker}} to fail with stacktraces 
> of when/where any unclosed instances were created - ie: which test method)
> In practice, I have managed to force one failure from {{StreamingTest}} since 
> the SOLR-16983 changes (logs to be attached soon) - but it still didn't 
> indicate any leaked/unclosed {{Http2SolrClient}} instances. What it instead 
> indicated was a _single_ unclosed {{InputStream}} instance related to 
> {{Http2SolrClient}} connections (SOLR-16983 also added better tracking of 
> this) coming from {{StreamingTest.testExceptionStream}} - a test method that 
> opens _five_ very similar {{ExceptionStream}} instances, wrapping 
> {{CloudSolrStream}} instance, which expect to trigger server side errors.
> By it's very design, {{ExceptionStream}} catches & records any exceptions 
> from the stream it wraps, so even in the event of these "expected" server 
> side errors, {{ExceptionStream.close()}} should still be correctly getting 
> called (and propagating down to the {{CloudStream}} it wraps).
> I believe the underlying problem has to do with a concurrency race condition 
> between the call to {{CloudStream.close()}} and the {{ExecutorService}} used 
> internally by {{CloudSolrStream.openStreams()}} (details to follow)



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

[GitHub] [solr] stillalex merged pull request #1955: SOLR-16992 Non-reproducible StreamingTest failures

2023-09-27 Thread via GitHub 


stillalex merged PR #1955:
URL: https://github.com/apache/solr/pull/1955


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

[GitHub] [solr-operator] HoustonPutman opened a new pull request, #634: Get correct SolrPods in SolrCloud controller

2023-09-27 Thread via GitHub 


HoustonPutman opened a new pull request, #634:
URL: https://github.com/apache/solr-operator/pull/634

   The SolrCloud controller needs to fetch the list of Solr Pods for a given 
SolrCloud, in order to determine what to restart and construct the 
SolrCloud.Status object. However, when an old SolrCloud has been deleted and a 
new SolrCloud has been created (with the same name), there may be time when the 
new SolrCloud has been created, but the Pods for the old SolrCloud have not yet 
been deleted. So the SolrCloud controller will then think that the old Pods are 
related to the new SolrCloud, because they have the right labels. This isn't 
the case however, so we need to make sure that only the SolrCloud Pods that are 
actually related to that SolrCloud are fetched.
   
   This is unlikely to show up in a production setting, but it causes havoc 
with the integration tests more than occasionally.
   
   I have also added the StatefulSet json to the output for integration tests, 
allowing us to better debug failures.


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

[GitHub] [solr-operator] HoustonPutman opened a new pull request, #633: Upgrade dependencies

2023-09-27 Thread via GitHub 


HoustonPutman opened a new pull request, #633:
URL: https://github.com/apache/solr-operator/pull/633

   This includes `controller-runtime` and the Kubernetes APIs.


-- 
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-17000) ExecutorUtilTest failures due to bad concurrency assumptions in test logic

2023-09-27 Thread Chris M. Hostetter (Jira) 


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

Chris M. Hostetter commented on SOLR-17000:
---

{quote}Any reason not using ExecutorUtil.shutdownNowAndAwaitTermination?

...

I think I saw "executorService.shutdownNow();" twice in the patch without using 
ExecutorUtil.
{quote}
Well ...
 # {{ExecutorUtil.shutdownNowAndAwaitTermination}} doesn't take in a timeout, 
so the test would have to wait the full 60 seconds
 # Even if it did have a timeout – we wouldn't want to use that method, because 
it's actually important for the logic of the test that we 
{{awaitWorkerInteruptedAtLeastOnce()}} _between_ the call to {{shutdownNow}} 
and the call to {{awaitTermination()}}

...but in terms of the last resort cleanup in the {{finally}} blocks ... sure, 
that could be {{ExecutorUtil.shutdownNowAndAwaitTermination}} ... i'll update 
the patch when i get a chance.

 

> ExecutorUtilTest failures due to bad concurrency assumptions in test logic
> --
>
> Key: SOLR-17000
> URL: https://issues.apache.org/jira/browse/SOLR-17000
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17000.patch, 
> apache_solr_Solr-check-9.3_647.log.txt, apache_solr_Solr-check-9.3_665.log.txt
>
>
> The basic logic of {{ExecutorUtilTest.testExecutorUtilAwaitsTerminationEnds}} 
> in psuedo code is...
> {code:java}
> Future f = executorService.submit(newTaskSleepAndIgnoreInterupts(300ms))  
>  // L45
> executorService.shutdownNow();
>  // L46
> assertThrows(RuntimeException,
>  // L47
>  ExecutorUtil.awaitTermination(executorService, 100ms)
> // Thread should not have finished in await termination.  
>  
> assertFalse(f.isDone());  
>  // L53
> {code}
> There are at least two concurrency assumptions here that are not guaranteed 
> to be true, and occasionally cause jenkins failures...
>  * There is no guarantee that the task submitted on line 45 will start before 
> the {{shutdownNow()}} call on line 46 – which means {{awaitTermination()}} 
> can succeed w/o throwing an exception:
> {noformat}
> // apache_solr_Solr-check-9.3_665.log.txt
> org.apache.solr.common.util.ExecutorUtilTest > 
> testExecutorUtilAwaitsTerminationEnds FAILED
> java.lang.AssertionError: expected java.lang.RuntimeException to be 
> thrown, but nothing was thrown
> at 
> __randomizedtesting.SeedInfo.seed([7169EEE284A03087:DFB4E65167A857BF]:0)
> at org.junit.Assert.assertThrows(Assert.java:1028)
> at org.junit.Assert.assertThrows(Assert.java:981)
> at 
> org.apache.solr.common.util.ExecutorUtilTest.testExecutorUtilAwaitsTerminationEnds(ExecutorUtilTest.java:47)
> {noformat}
>  * From the perspective of the test thread, it's guaranteed that _at least_ 
> 100ms has elapsed (since line 45) by the time {{awaitTermination()}} throws 
> it's exception, but that doesn't preclude the possibility that by the time 
> the test thread gets to line 53, a full 300ms may have elapsed, and the 
> background thread has already finished the task, so that the  
> {{Future.isDone()}} call may return true:
> {noformat}
> // apache_solr_Solr-check-9.3_647.log.txt
> org.apache.solr.common.util.ExecutorUtilTest > 
> testExecutorUtilAwaitsTerminationEnds FAILED
> java.lang.AssertionError
> at __randomizedtesting.SeedInfo.seed([F7AFD5785E583017:5972DDCBBD50572F]:0)
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at 
> org.apache.solr.common.util.ExecutorUtilTest.testExecutorUtilAwaitsTerminationEnds(ExecutorUtilTest.java:53)
> {noformat}



--
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-16992) Non-reproducible StreamingTest failures -- suggests CloudSolrStream concurency race condition

2023-09-27 Thread Chris M. Hostetter (Jira) 


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

Chris M. Hostetter commented on SOLR-16992:
---

{quote}I had already moved the null filtering so no trouble there.
{quote}
right.  my point in that comment was that if you were sure all of the 
{{StreamExecutorHelper.submitAllAndAwaitAggregatingExceptions()}} callers 
didn't care about nulls, and you want to move the null check _BACK_ into 
{{StreamExecutorHelper.submitAllAndAwaitAggregatingExceptions()}} i'd be fine 
with that either way.
{quote}sure changed to Collection
{quote}
I think the javadocs may still refer to the results as a "list" ?
{quote}all is missing is a quick +1 ;)
{quote}
Oh, Sorry ... I'm definitely +1 ... this is all just nitpick.

commit & backport whenever you're happy

> Non-reproducible StreamingTest failures -- suggests CloudSolrStream 
> concurency race condition
> -
>
> Key: SOLR-16992
> URL: https://issues.apache.org/jira/browse/SOLR-16992
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Chris M. Hostetter
>Assignee: Alex Deparvu
>Priority: Major
> Attachments: 
> OUTPUT-org.apache.solr.client.solrj.io.stream.StreamingTest.txt, 
> thetaphi_solr_Solr-main-Linux_14679.log.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Roughly 3% of all jenkins jobs that run {{StreamingTest}} wind up having 
> suite level failures.
> These failures have historically taken the form of 
> {{com.carrotsearch.randomizedtesting.ThreadLeakError}} and the leaked threads 
> all have names like
> {{"h2sc-718-thread-2"}} indicating that they come from the internal 
> {{ExecutorService}} of an {{{}Http2SolrClient{}}}.
> In my experience, the seeds from these failures have never reproduced - 
> suggesting that the problem is related to concurrency.
> SOLR-16983 restored the (correct) use of {{ObjectReleaseTracker}} which in 
> theory should help pinpoint where {{Http2SolrClient}} instances might not be 
> getting closed (by causing {{ObjectReleaseTracker}} to fail with stacktraces 
> of when/where any unclosed instances were created - ie: which test method)
> In practice, I have managed to force one failure from {{StreamingTest}} since 
> the SOLR-16983 changes (logs to be attached soon) - but it still didn't 
> indicate any leaked/unclosed {{Http2SolrClient}} instances. What it instead 
> indicated was a _single_ unclosed {{InputStream}} instance related to 
> {{Http2SolrClient}} connections (SOLR-16983 also added better tracking of 
> this) coming from {{StreamingTest.testExceptionStream}} - a test method that 
> opens _five_ very similar {{ExceptionStream}} instances, wrapping 
> {{CloudSolrStream}} instance, which expect to trigger server side errors.
> By it's very design, {{ExceptionStream}} catches & records any exceptions 
> from the stream it wraps, so even in the event of these "expected" server 
> side errors, {{ExceptionStream.close()}} should still be correctly getting 
> called (and propagating down to the {{CloudStream}} it wraps).
> I believe the underlying problem has to do with a concurrency race condition 
> between the call to {{CloudStream.close()}} and the {{ExecutorService}} used 
> internally by {{CloudSolrStream.openStreams()}} (details to follow)



--
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-16825) Generate Java bindings from OpenAPI spec

2023-09-27 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on SOLR-16825:


Commit 0c934fbf124190c683e75b7c817309093c0dd727 in solr's branch 
refs/heads/SOLR-16825-migrate-definitions-to-api-module-pt4 from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=0c934fbf124 ]

Merge branch 'main' into SOLR-16825-migrate-definitions-to-api-module-pt4


> Generate Java bindings from OpenAPI spec
> 
>
> Key: SOLR-16825
> URL: https://issues.apache.org/jira/browse/SOLR-16825
> Project: Solr
>  Issue Type: Improvement
>  Components: v2 API
>Reporter: Jason Gerlowski
>Priority: Major
>  Time Spent: 8.5h
>  Remaining Estimate: 0h
>
> SOLR-16346 added support to Solr's build to generate an "OpenAPI spec" file 
> describing our v2 API.  But currently, this spec file isn't actually used by 
> Solr in any way.
> Spec files can be used for a variety of purposes, including to [generate 
> client bindings|https://github.com/OpenAPITools/openapi-generator] for using 
> the API.
> The client generation capabilities provided by the OpenAPI project cover a 
> variety of languages, but it make sense for Solr to start with Java since we 
> already have a Java client that requires continual effort to keep up to date. 
>  It'd be a big win for the project if we were able to replace some or all of 
> the manually maintained "SolrRequest" implementations in SolrJ with 
> automatically generated code.  



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

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

[jira] [Commented] (SOLR-17001) Adjust workaround for JDK17 bug so it only applies to specific versions with the bug

2023-09-27 Thread Shawn Heisey (Jira) 


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

Shawn Heisey commented on SOLR-17001:
-

Attached patch with a finished and tested shell script change.  Patch also 
includes changes for Windows, but those have not been tested yet.  I 
accidentally killed the storage on my own Windows machine, will need to borrow 
one for testing.

> Adjust workaround for JDK17 bug so it only applies to specific versions with 
> the bug
> 
>
> Key: SOLR-17001
> URL: https://issues.apache.org/jira/browse/SOLR-17001
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 9.3
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
>  Labels: patch
> Attachments: SOLR-17001.patch
>
>
> SOLR-16463 added a workaround in the bin/solr and bin\solr.cmd scripts for a 
> bug in JDK 17 and 19.  That workaround assumes that any Java version 17 or 
> later is affected.
> At the time the workaround was implemented, there were no released Java 
> versions without the bug.  Now there are.
> This issue will add detection for good and bad Java versions.



--
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-17001) Adjust workaround for JDK17 bug so it only applies to specific versions with the bug

2023-09-27 Thread Shawn Heisey (Jira) 


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

Shawn Heisey updated SOLR-17001:

Attachment: SOLR-17001.patch

> Adjust workaround for JDK17 bug so it only applies to specific versions with 
> the bug
> 
>
> Key: SOLR-17001
> URL: https://issues.apache.org/jira/browse/SOLR-17001
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 9.3
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
>  Labels: patch
> Attachments: SOLR-17001.patch
>
>
> SOLR-16463 added a workaround in the bin/solr and bin\solr.cmd scripts for a 
> bug in JDK 17 and 19.  That workaround assumes that any Java version 17 or 
> later is affected.
> At the time the workaround was implemented, there were no released Java 
> versions without the bug.  Now there are.
> This issue will add detection for good and bad Java versions.



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

[GitHub] [solr] janhoy commented on pull request #1806: Update dependency org.xerial.snappy:snappy-java to v1.1.10.3

2023-09-27 Thread via GitHub 


janhoy commented on PR #1806:
URL: https://github.com/apache/solr/pull/1806#issuecomment-1737755069

   I created a blocker JIRA for it in 
https://issues.apache.org/jira/browse/SOLR-17002 that will hold the 9.4 release 
until this is merged.


-- 
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-17002) Update dependency org.xerial.snappy:snappy-java to v1.1.10.4

2023-09-27 Thread Jira 
Jan Høydahl created SOLR-17002:
--

 Summary: Update dependency org.xerial.snappy:snappy-java to 
v1.1.10.4
 Key: SOLR-17002
 URL: https://issues.apache.org/jira/browse/SOLR-17002
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Jan Høydahl


Merge [https://github.com/apache/solr/pull/1806] once we have v1.1.10.4 (or 
newer)



--
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-17002) Update dependency org.xerial.snappy:snappy-java to v1.1.10.4

2023-09-27 Thread Jira 


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

Jan Høydahl updated SOLR-17002:
---
Fix Version/s: 9.4

> Update dependency org.xerial.snappy:snappy-java to v1.1.10.4
> 
>
> Key: SOLR-17002
> URL: https://issues.apache.org/jira/browse/SOLR-17002
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 9.4
>
>
> Merge [https://github.com/apache/solr/pull/1806] once we have v1.1.10.4 (or 
> newer)



--
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-17002) Update dependency org.xerial.snappy:snappy-java to v1.1.10.4

2023-09-27 Thread Jira 


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

Jan Høydahl updated SOLR-17002:
---
Priority: Blocker  (was: Major)

> Update dependency org.xerial.snappy:snappy-java to v1.1.10.4
> 
>
> Key: SOLR-17002
> URL: https://issues.apache.org/jira/browse/SOLR-17002
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jan Høydahl
>Priority: Blocker
> Fix For: 9.4
>
>
> Merge [https://github.com/apache/solr/pull/1806] once we have v1.1.10.4 (or 
> newer)



--
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-17001) Adjust workaround for JDK17 bug so it only applies to specific versions with the bug

2023-09-27 Thread Shawn Heisey (Jira) 
Shawn Heisey created SOLR-17001:
---

 Summary: Adjust workaround for JDK17 bug so it only applies to 
specific versions with the bug
 Key: SOLR-17001
 URL: https://issues.apache.org/jira/browse/SOLR-17001
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Affects Versions: 9.3
Reporter: Shawn Heisey
Assignee: Shawn Heisey


SOLR-16463 added a workaround in the bin/solr and bin\solr.cmd scripts for a 
bug in JDK 17 and 19.  That workaround assumes that any Java version 17 or 
later is affected.

At the time the workaround was implemented, there were no released Java 
versions without the bug.  Now there are.

This issue will add detection for good and bad Java versions.



--
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-16992) Non-reproducible StreamingTest failures -- suggests CloudSolrStream concurency race condition

2023-09-27 Thread Alex Deparvu (Jira) 


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

Alex Deparvu commented on SOLR-16992:
-

[~hossman] I think this covers everything. all is missing is a quick +1 ;)

> Non-reproducible StreamingTest failures -- suggests CloudSolrStream 
> concurency race condition
> -
>
> Key: SOLR-16992
> URL: https://issues.apache.org/jira/browse/SOLR-16992
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Chris M. Hostetter
>Assignee: Alex Deparvu
>Priority: Major
> Attachments: 
> OUTPUT-org.apache.solr.client.solrj.io.stream.StreamingTest.txt, 
> thetaphi_solr_Solr-main-Linux_14679.log.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Roughly 3% of all jenkins jobs that run {{StreamingTest}} wind up having 
> suite level failures.
> These failures have historically taken the form of 
> {{com.carrotsearch.randomizedtesting.ThreadLeakError}} and the leaked threads 
> all have names like
> {{"h2sc-718-thread-2"}} indicating that they come from the internal 
> {{ExecutorService}} of an {{{}Http2SolrClient{}}}.
> In my experience, the seeds from these failures have never reproduced - 
> suggesting that the problem is related to concurrency.
> SOLR-16983 restored the (correct) use of {{ObjectReleaseTracker}} which in 
> theory should help pinpoint where {{Http2SolrClient}} instances might not be 
> getting closed (by causing {{ObjectReleaseTracker}} to fail with stacktraces 
> of when/where any unclosed instances were created - ie: which test method)
> In practice, I have managed to force one failure from {{StreamingTest}} since 
> the SOLR-16983 changes (logs to be attached soon) - but it still didn't 
> indicate any leaked/unclosed {{Http2SolrClient}} instances. What it instead 
> indicated was a _single_ unclosed {{InputStream}} instance related to 
> {{Http2SolrClient}} connections (SOLR-16983 also added better tracking of 
> this) coming from {{StreamingTest.testExceptionStream}} - a test method that 
> opens _five_ very similar {{ExceptionStream}} instances, wrapping 
> {{CloudSolrStream}} instance, which expect to trigger server side errors.
> By it's very design, {{ExceptionStream}} catches & records any exceptions 
> from the stream it wraps, so even in the event of these "expected" server 
> side errors, {{ExceptionStream.close()}} should still be correctly getting 
> called (and propagating down to the {{CloudStream}} it wraps).
> I believe the underlying problem has to do with a concurrency race condition 
> between the call to {{CloudStream.close()}} and the {{ExecutorService}} used 
> internally by {{CloudSolrStream.openStreams()}} (details to follow)



--
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-16935) Add spans to cover gaps in query processing

2023-09-27 Thread Alex Deparvu (Jira) 


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

Alex Deparvu commented on SOLR-16935:
-

it was paused on [~dsmiley]'s request. but I think I will come back and refresh 
the PR. ideally it goes to 9.x too but backports are involved so probably a 
different PR will be raised for 9.x backport.

> Add spans to cover gaps in query processing
> ---
>
> Key: SOLR-16935
> URL: https://issues.apache.org/jira/browse/SOLR-16935
> Project: Solr
>  Issue Type: Improvement
>  Components: tracing
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Minor
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> I think it would be good to cover the query processing + response end to end, 
> have minimal gaps in spans. In my original proposal for SOLR-16536 I had 
> added 2 more: one span for query response write, and another one for the 
> request body handling.
> Will open a PR with some examples once SOLR-16536 is in.



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

[GitHub] [solr] epugh commented on pull request #1954: SOLR-14496: Add Basic Auth support to SolrCLI

2023-09-27 Thread via GitHub 


epugh commented on PR #1954:
URL: https://github.com/apache/solr/pull/1954#issuecomment-1737508322

   Holy smokes, almost everything is building/running cleanly, and that crave 
failure of 
`org.apache.solr.cli.DeleteToolTest.testFailsToDeleteProtectedCollection` runs 
locally just fine..  (?)...I am down to messing with the PackageTool for 
https, and then will be looking for reveiw and some thumbs up.
   


-- 
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-16441) Upgrade Jetty to 11.x

2023-09-27 Thread Eric Pugh (Jira) 


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

Eric Pugh commented on SOLR-16441:
--

I looked at the summary of the changes (love how it was structured), and kind 
of poked through the code in the PR, and it looks like some really great work 
to make this migration, thank you [~krisden]. Making this jump isn't going 
to ever be an easy thing, and the longer we wait, the further behind we will 
get.  I'd love to see this happen in Solr 10 as well.

As far as the Hadoop thing, how can we get a decision on that?  Can we move 
Hadoop to it's own project that stays on Solr 9 till that community is ready, 
similar to how we handled DIH?

> Upgrade Jetty to 11.x
> -
>
> Key: SOLR-16441
> URL: https://issues.apache.org/jira/browse/SOLR-16441
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in 
> SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to 
> jakarta namespace for servlet.
>  



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

[GitHub] [solr] risdenk commented on pull request #1945: SOLR-13833-setupRequest-improvements

2023-09-27 Thread via GitHub 


risdenk commented on PR #1945:
URL: https://github.com/apache/solr/pull/1945#issuecomment-1737383196

   @psalagnac @patsonluk I pushed 
[7532168](https://github.com/apache/solr/pull/1945/commits/7532168b7813cf0c64ef1c935c0a1d9b0527e25f)
 which checks the predicate in waitForState


-- 
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-17000) ExecutorUtilTest failures due to bad concurrency assumptions in test logic

2023-09-27 Thread Kevin Risden (Jira) 


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

Kevin Risden commented on SOLR-17000:
-

[~hossman] thanks this looks great. One comment about the patch:

Any reason not using ExecutorUtil.shutdownNowAndAwaitTermination?
{code:java}
executorService.shutdownNow();
ExecutorUtil.awaitTermination({code}
I think I saw "executorService.shutdownNow();" twice in the patch without using 
ExecutorUtil.

> ExecutorUtilTest failures due to bad concurrency assumptions in test logic
> --
>
> Key: SOLR-17000
> URL: https://issues.apache.org/jira/browse/SOLR-17000
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17000.patch, 
> apache_solr_Solr-check-9.3_647.log.txt, apache_solr_Solr-check-9.3_665.log.txt
>
>
> The basic logic of {{ExecutorUtilTest.testExecutorUtilAwaitsTerminationEnds}} 
> in psuedo code is...
> {code:java}
> Future f = executorService.submit(newTaskSleepAndIgnoreInterupts(300ms))  
>  // L45
> executorService.shutdownNow();
>  // L46
> assertThrows(RuntimeException,
>  // L47
>  ExecutorUtil.awaitTermination(executorService, 100ms)
> // Thread should not have finished in await termination.  
>  
> assertFalse(f.isDone());  
>  // L53
> {code}
> There are at least two concurrency assumptions here that are not guaranteed 
> to be true, and occasionally cause jenkins failures...
>  * There is no guarantee that the task submitted on line 45 will start before 
> the {{shutdownNow()}} call on line 46 – which means {{awaitTermination()}} 
> can succeed w/o throwing an exception:
> {noformat}
> // apache_solr_Solr-check-9.3_665.log.txt
> org.apache.solr.common.util.ExecutorUtilTest > 
> testExecutorUtilAwaitsTerminationEnds FAILED
> java.lang.AssertionError: expected java.lang.RuntimeException to be 
> thrown, but nothing was thrown
> at 
> __randomizedtesting.SeedInfo.seed([7169EEE284A03087:DFB4E65167A857BF]:0)
> at org.junit.Assert.assertThrows(Assert.java:1028)
> at org.junit.Assert.assertThrows(Assert.java:981)
> at 
> org.apache.solr.common.util.ExecutorUtilTest.testExecutorUtilAwaitsTerminationEnds(ExecutorUtilTest.java:47)
> {noformat}
>  * From the perspective of the test thread, it's guaranteed that _at least_ 
> 100ms has elapsed (since line 45) by the time {{awaitTermination()}} throws 
> it's exception, but that doesn't preclude the possibility that by the time 
> the test thread gets to line 53, a full 300ms may have elapsed, and the 
> background thread has already finished the task, so that the  
> {{Future.isDone()}} call may return true:
> {noformat}
> // apache_solr_Solr-check-9.3_647.log.txt
> org.apache.solr.common.util.ExecutorUtilTest > 
> testExecutorUtilAwaitsTerminationEnds FAILED
> java.lang.AssertionError
> at __randomizedtesting.SeedInfo.seed([F7AFD5785E583017:5972DDCBBD50572F]:0)
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at 
> org.apache.solr.common.util.ExecutorUtilTest.testExecutorUtilAwaitsTerminationEnds(ExecutorUtilTest.java:53)
> {noformat}



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

[GitHub] [solr-sandbox] sigram commented on pull request #68: Add support for mirroring Collection Admin commands.

2023-09-27 Thread via GitHub 


sigram commented on PR #68:
URL: https://github.com/apache/solr-sandbox/pull/68#issuecomment-1737190410

   @markrmiller it is optional in the sense that you can leave the default 
CollectionsHandler (i.e. NOT configure this special CollectionsHandler) in your 
`solr.xml`. Should this be guarded also by an additional config property?
   
   Re. configuration ... I can move it to `KafkaCrossDcConf` but it's already 
somewhat messy because many config properties and the whole mechanism of 
reading env / sysprops should be moved from `KafkaCrossDcConf` to `CrossDcConf` 
... but that's something for a separate PR.


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

[GitHub] [solr] r-oldenburg commented on pull request #1806: Update dependency org.xerial.snappy:snappy-java to v1.1.10.3

2023-09-27 Thread via GitHub 


r-oldenburg commented on PR #1806:
URL: https://github.com/apache/solr/pull/1806#issuecomment-1737041391

   I am a little worried as this PR is already some 10 weeks old... When is 
this going to be merged?


-- 
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-15960) Unified use of system properties and environment variables

2023-09-27 Thread Jira 


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

Jan Høydahl commented on SOLR-15960:


While researching IOC/DI frameworks I found Avaje Config 
[https://avaje.io/config/] which is a nice Config library that seems to be 
doing all of what my PR does and more. Maybe even a way to replace solr.xml 
with a config yaml with property expansion ootb. Have a look and tell me what 
you think.

> Unified use of system properties and environment variables
> --
>
> Key: SOLR-15960
> URL: https://issues.apache.org/jira/browse/SOLR-15960
> Project: Solr
>  Issue Type: Improvement
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> We have a lot of boiler-plate code in Solr related to resolving configuration 
> from config-files, system properties and environment variables.
> The main pattern so far has been to load a config from an xml file, which 
> uses system property variables like {{{}$\{myVar{. All the environment 
> variables that we expose in {{solr.in.sh}} are converted to system.properties 
> in {{bin/solr}} and inside of Solr we only care about sys.props. This has 
> served us quite well, but is also has certain disadvantages:
>  * Naming mismatches. You have one config name in the xml file, one as system 
> property and yet another for environment variable.
>  * Duplicate code to deal with type conversion, and converting comma 
> separated lists from env.var into Java lists
>  * Every new config option needs to touch {{{}bin/solr{}}}, {{bin/solr.cmd}} 
> and often more.
> In the world of containers and k8s, we want to configure almost every aspect 
> of an app using environment variables. It is sometimes also more secure than 
> passing sys.props on the cmdline since they won't show up in a "ps".
> So this is a proposal to unify all Solr's configs in a more structured way
>  * Make naming a convention. All env.variable should be uppercase with format 
> {{SOLR_X_Y}} and all sys.propos should be lowercase with the format 
> {{solr.x.y}}. Perhaps {{solr.camelCase}} should map to {{SOLR_CAMEL_CASE}}, 
> or we discourage camel case in favour of dots.
>  * Add a central {{ConfigResolver}} class to Solr that can answer e.g. 
> {{getInt("solr.my.number")}} and it would return either prop 
> {{solr.my.number}} or {{SOLR_MY_NUMBER}}. Similar for String, bool etc, and 
> with fallback-values
>  * List support, e.g. {{getListOfStrings("solr.modules")}} and it would 
> return a {{List}} from either {{solr.modules}} or {{SOLR_MODULES}}, 
> supporting comma-separated, custom separator and why not also json list 
> format ["foo","bar"]?
> A pitfall of using environment variables directly is testing, since env.vars 
> are immutable. I suggest we solve this by reading all {{SOLR_*}} 
> env.variables on startup and inserting them into a static, mutable map 
> somewhere which is the single source of truth for env.vars. Then we can ban 
> the use of {{System.getenv()}}.



--
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-16935) Add spans to cover gaps in query processing

2023-09-27 Thread Jira 


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

Jan Høydahl commented on SOLR-16935:


What is the status of this work? Is it intended for 10.0 only?

> Add spans to cover gaps in query processing
> ---
>
> Key: SOLR-16935
> URL: https://issues.apache.org/jira/browse/SOLR-16935
> Project: Solr
>  Issue Type: Improvement
>  Components: tracing
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Minor
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> I think it would be good to cover the query processing + response end to end, 
> have minimal gaps in spans. In my original proposal for SOLR-16536 I had 
> added 2 more: one span for query response write, and another one for the 
> request body handling.
> Will open a PR with some examples once SOLR-16536 is in.



--
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-16441) Upgrade Jetty to 11.x

2023-09-27 Thread Jira 


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

Thomas Wöckinger commented on SOLR-16441:
-

At least this should be part of Solr 10

> Upgrade Jetty to 11.x
> -
>
> Key: SOLR-16441
> URL: https://issues.apache.org/jira/browse/SOLR-16441
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in 
> SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to 
> jakarta namespace for servlet.
>  



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

[GitHub] [solr] Raghavan1988 commented on pull request #1842: SOLR-16644 Fixing the entropy warning threshold based on OS ubuntu an…

2023-09-27 Thread via GitHub 


Raghavan1988 commented on PR #1842:
URL: https://github.com/apache/solr/pull/1842#issuecomment-1736836920

   I updated the PR where the check is based on the ratio instead of hard coded 
threshold. @chatman  - Please review.


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