[GitHub] [lucene-solr] CaoManhDat commented on a change in pull request #1770: SOLR-14763 SolrJ HTTP/2 Async API using CompletableFuture
CaoManhDat commented on a change in pull request #1770:
URL: https://github.com/apache/lucene-solr/pull/1770#discussion_r474462958
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java
##
@@ -394,26 +393,26 @@ public void onHeaders(Response response) {
assert ObjectReleaseTracker.track(is);
try {
NamedList body = processErrorsAndResponse(solrRequest,
parser, response, is);
-asyncListener.onSuccess(body);
- } catch (RemoteSolrException e) {
-if (SolrException.getRootCause(e) != CANCELLED_EXCEPTION) {
- asyncListener.onFailure(e);
-}
- } catch (SolrServerException e) {
-asyncListener.onFailure(e);
+future.complete(body);
+ } catch (RemoteSolrException | SolrServerException e) {
+future.completeExceptionally(e);
}
});
}
@Override
public void onFailure(Response response, Throwable failure) {
super.onFailure(response, failure);
-if (failure != CANCELLED_EXCEPTION) {
- asyncListener.onFailure(new
SolrServerException(failure.getMessage(), failure));
-}
+future.completeExceptionally(new
SolrServerException(failure.getMessage(), failure));
}
});
-return () -> req.abort(CANCELLED_EXCEPTION);
+future.exceptionally((error) -> {
+ if (error instanceof CancellationException) {
+req.abort(new Exception());
Review comment:
> Although the exception would be called by listeners, wouldn't the
future.completeExceptionally that is used to handle the exception be a noop as
the future has already been cancelled?
I see your point, but I in this case from CompletableFuture perspective, it
get called with `cancel()` first then `completeExceptionally` will that mess up
with internal state of the future instance?
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9472) True concurrent test suite duplication and execution (beasting)
[
https://issues.apache.org/jira/browse/LUCENE-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181693#comment-17181693
]
Dawid Weiss commented on LUCENE-9472:
-
This is the bit that causes invalid progress info to show up only once:
https://github.com/gradle/gradle/blob/e975872ae2cf1d521b73f1107cae772ca09c63cd/subprojects/testing-base/src/main/java/org/gradle/api/internal/tasks/testing/logging/TestWorkerProgressListener.java#L65-L72
> True concurrent test suite duplication and execution (beasting)
> ---
>
> Key: LUCENE-9472
> URL: https://issues.apache.org/jira/browse/LUCENE-9472
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I toyed with this a bit because it's hacker's delight... Forked the default
> Gradle test task and made it emit the same test/ suite name multiple times.
> This results in the same test being executed multiple times:
> {code}
> # ./gradlew -p lucene\analysis\kuromoji testy --tests
> TestToStringUtil.testHepburn -Ptests.dups=10
> > Task :randomizationInfo
> Running tests with randomization seed: tests.seed=88C21B0E8ABB2D46
> > Task :lucene:analysis:kuromoji:testy
> :lucene:analysis:kuromoji:testy (SUCCESS): 10 test(s)
> BUILD SUCCESSFUL in 13s
> 21 actionable tasks: 6 executed, 15 up-to-date
> {code}
> Upsides:
> * Everything configures itself because the custom task is a subtype of
> Gradle's Test task,
> * Tests are run in parallel, on multiple VMs,
> * Opens up the possibility of reordering test suites (for load-balancing).
> Downsides:
> * Requires a custom(ized) clone of Gradle's internal classes. Will require
> maintenance when upgrading gradle. There is no certainty it'll work.
> * Some things visibly don't like duplicated suite names - the progress bar
> shows the suite once, even though it is executed concurrently in multiple VMs,
> * XML reports will drive jenkins and other tooling crazy:
> {code}
>
> tests="10" skipped="0" failures="0" errors="0"
> timestamp="2020-08-20T12:54:27" hostname="DWEISS-DESKTOP" time="3.177">
>
>classname="org.apache.lucene.analysis.ja.util.TestToStringUtil" time="1.04"/>
>classname="org.apache.lucene.analysis.ja.util.TestToStringUtil" time="1.045"/>
>classname="org.apache.lucene.analysis.ja.util.TestToStringUtil" time="1.043"/>
>classname="org.apache.lucene.analysis.ja.util.TestToStringUtil" time="1.038"/>
>classname="org.apache.lucene.analysis.ja.util.TestToStringUtil" time="1.008"/>
>classname="org.apache.lucene.analysis.ja.util.TestToStringUtil" time="1.005"/>
>
> {code}
> * not sure what happens with sysouts from such concurrent runs...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] CaoManhDat merged pull request #1724: SOLR-14684: CloudExitableDirectoryReaderTest failing about 25% of the time
CaoManhDat merged pull request #1724: URL: https://github.com/apache/lucene-solr/pull/1724 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14684) CloudExitableDirectoryReaderTest failing about 25% of the time
[ https://issues.apache.org/jira/browse/SOLR-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181724#comment-17181724 ] ASF subversion and git services commented on SOLR-14684: Commit 2b2b9e71d3defe6aa4578f9a571078de8b88c7c6 in lucene-solr's branch refs/heads/master from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2b2b9e7 ] SOLR-14684: CloudExitableDirectoryReaderTest failing about 25% of the time (#1724) > CloudExitableDirectoryReaderTest failing about 25% of the time > -- > > Key: SOLR-14684 > URL: https://issues.apache.org/jira/browse/SOLR-14684 > Project: Solr > Issue Type: Test > Components: Tests >Affects Versions: master (9.0) >Reporter: Erick Erickson >Priority: Major > Attachments: stdout > > Time Spent: 40m > Remaining Estimate: 0h > > If I beast this on my local machine, it fails (non reproducibly of course) > about 1/4 of the time. Log attached. The test itself hasn't changed in 11 > months or so. > It looks like occasionally the calls throw an error rather than return > partial results with a message: "Time allowed to handle this request > exceeded:[]". > It's been failing very intermittently for a couple of years, but the failure > rate really picked up in the last couple of weeks. IDK whether the failures > prior to the last couple of weeks are the same root cause. > I'll do some spelunking to see if I can pinpoint the commit that made this > happen, but it'll take a while. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] der-eismann opened a new pull request #1771: SOLR-14752: Fix zk status with prometheus enabled zookeeper
der-eismann opened a new pull request #1771: URL: https://github.com/apache/lucene-solr/pull/1771 # Description Solr checks the zookeeper status in the admin UI and explicitly expects integers to be delivered. However if you enable the prometheus plugin in zookeeper, all values are posted as floats instead which breaks the existing check. # Solution This is a small fix to parse the values as floats and cast them into an integer. This should be fine since the number of followers can't actually be a float and the part behind the dot is always 0. # Tests None. This is my first Java contribution ever, so I'm happy for any clue how to do this. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14768) Error 500 on PDF extraction: java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts
[
https://issues.apache.org/jira/browse/SOLR-14768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181807#comment-17181807
]
Joe Doupnik commented on SOLR-14768:
May I add my parallel report on the same problem.
Where as this works with Solr v8.5.0, on v8.6.0 and 8.6.1, operations fail
when Solr encounters multipart mime formatted commands used with POST. Commands
are being issued by PHP v5 and v7 programs. A PHP source program snippet:
{quote}!oQy99opGysZIoiIaDYxRDickBJCSYx9
wTnzjfh4KE6POjuYu01ERHNOYYIhzO3Zlors80V3nN9YURE9NxjiHA4c97BPvfAUxhEROQEDBEOZ1Ze8xQGERE5DUOEw1nBQSpIIRB7OsEQQUREjsAQ4XBKKuslhTQrLAH
vRER0RxjiCAiIqIZYYggIiKiGWGIICIiohlhiCAiIqIZYYggIiKiGfkPYYHkPAZ30LQASUVORK5CYII=|width=529,height=477!{quote}
This produces output of Deleteindex errno=22 and the index is not deleted.
More, when submitting files for indexing. Again error 22 is returned, and
the curl response is "false".
While debugging the root of this is handling multipart mime encoded commands
and the HTTP ERROR 500 message is the tell-tale:
First the generating program part:
{quote}!jJWyYq9UGRgASUVORK5CYII=|width=474,height=297!{quote}
Then the wireshark analysis of the exchange. A piece of the update/extract
request packet showing MIME parts:
{quote}!llxONJcwv8BG TQnV9PkiIASUVORK5CYII=|width=657,height=365!{quote}
Below is what the 500 Server Error packet contains:
{quote}!dv0naZp r3ofwA0bvHrGPWbVABJRU5ErkJggg==|width=676,height=283!{quote}
...
In this file submission case the file is actually submitted and indexed,
but the server's response is failure with error code 22.
Again, one key to this puzzle is that NoClassDefFoundError for MultiParts. The
java code for that area differs dramatically between Solr 8.5 and 8.6.
Thanks,
Joe D.
> Error 500 on PDF extraction: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiParts
>
>
> Key: SOLR-14768
> URL: https://issues.apache.org/jira/browse/SOLR-14768
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Solr Cell (Tika extraction)
>Affects Versions: 8.6, 8.6.1
>Reporter: Markus Kalkbrenner
>Priority: Major
>
> See [https://www.mail-archive.com/solr-user@lucene.apache.org/msg152182.html]
> The integration tests of the solarium PHP library and the integration tests
> of the Search API Solr Drupal module both fail on PDF extraction if executed
> on Solr 8.6.
> They still work on Solr 8.5.1 an earlier versions.
> {quote}2020-08-20 12:30:35.279 INFO (qtp855700733-19) [ x:5f3e6ce2810ef]
> o.a.s.u.p.LogUpdateProcessorFactory [5f3e6ce2810ef] webapp=/solr
> path=/update/extract
> params=\{json.nl=flat&commitWithin=0&omitHeader=false&resource.name=testpdf.pdf&literal.id=extract-test&commit=true&extractOnly=false&uprefix=attr_&wt=json}{add=[extract-test
> (1675547519474466816)],commit=} 0 957
> solr8_1 | 2020-08-20 12:30:35.280 WARN (qtp855700733-19) [ ]
> o.e.j.s.HttpChannel /solr/5f3e6ce2810ef/update/extract =>
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts
> solr8_1 | at
> org.apache.solr.servlet.SolrRequestParsers.cleanupMultipartFiles(SolrRequestParsers.java:624)
> solr8_1 | java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts
> solr8_1 | at
> org.apache.solr.servlet.SolrRequestParsers.cleanupMultipartFiles(SolrRequestParsers.java:624)
> ~[?:?]
> solr8_1 | at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:443)
> ~[?:?]
> solr8_1 | at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> ~[?:?]
> solr8_1 | at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> ~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> ~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> ~[jetty-security-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> ~[jetty-server-9.4.27.v202
[jira] [Updated] (LUCENE-9313) Analyzer for Serbian language based on Snowball stemmer
[ https://issues.apache.org/jira/browse/LUCENE-9313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Ivanovic updated LUCENE-9313: Description: My colleague and myself developed snowball stemmer for Serbian language recently: [https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sbl|https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sb] [https://snowballstem.org/algorithms/serbian/stemmer.html] We have a Serbian Lucene analyzer developed on top of that stemmer, and we would like to make a contribution to Lucene. was: My colleague and myself developed snowball stemmer for Serbian language recently: [https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sb] [https://snowballstem.org/algorithms/serbian/stemmer.html] We have a Serbian Lucene analyzer developed on top of that stemmer, and we would like to make a contribution to Lucene. > Analyzer for Serbian language based on Snowball stemmer > --- > > Key: LUCENE-9313 > URL: https://issues.apache.org/jira/browse/LUCENE-9313 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Dragan Ivanovic >Priority: Major > > My colleague and myself developed snowball stemmer for Serbian language > recently: > [https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sbl|https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sb] > > [https://snowballstem.org/algorithms/serbian/stemmer.html] > We have a Serbian Lucene analyzer developed on top of that stemmer, and we > would like to make a contribution to Lucene. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9313) Analyzer for Serbian language based on Snowball stemmer
[ https://issues.apache.org/jira/browse/LUCENE-9313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Ivanovic updated LUCENE-9313: Status: Patch Available (was: Open) > Analyzer for Serbian language based on Snowball stemmer > --- > > Key: LUCENE-9313 > URL: https://issues.apache.org/jira/browse/LUCENE-9313 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Dragan Ivanovic >Priority: Major > > My colleague and myself developed snowball stemmer for Serbian language > recently: > [https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sbl|https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sb] > > [https://snowballstem.org/algorithms/serbian/stemmer.html] > We have a Serbian Lucene analyzer developed on top of that stemmer, and we > would like to make a contribution to Lucene. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9313) Analyzer for Serbian language based on Snowball stemmer
[ https://issues.apache.org/jira/browse/LUCENE-9313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Ivanovic updated LUCENE-9313: Status: Open (was: Patch Available) > Analyzer for Serbian language based on Snowball stemmer > --- > > Key: LUCENE-9313 > URL: https://issues.apache.org/jira/browse/LUCENE-9313 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Dragan Ivanovic >Priority: Major > > My colleague and myself developed snowball stemmer for Serbian language > recently: > [https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sbl|https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sb] > > [https://snowballstem.org/algorithms/serbian/stemmer.html] > We have a Serbian Lucene analyzer developed on top of that stemmer, and we > would like to make a contribution to Lucene. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14754) Hyperlinks on Solr Admin not working
[ https://issues.apache.org/jira/browse/SOLR-14754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181846#comment-17181846 ] David Eric Pugh commented on SOLR-14754: Thanks [~utsuk.pr...@gmail.com] for testing that! I've had a feeling that we need to version our Javascript assets by release to ensure that we aren't loading cached files as we change versions of Solr. [~janhoy] have you seen this as well? Does this sound like something you've seen? If we want to do this, should we open a different JIRA, or just update this one? > Hyperlinks on Solr Admin not working > > > Key: SOLR-14754 > URL: https://issues.apache.org/jira/browse/SOLR-14754 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.6, 8.6.1 >Reporter: Utsuk Prani >Priority: Major > Labels: admin-interface > Attachments: solr8.6.1_bug.png > > > I am working with SOLR 8.6.1 (same problem also happening in 8.6.0). > OS - Windows 10 Enterprise > Browser - Chrome (Version 84.0.4147.125 (Official Build) (64-bit)) > Steps to reproduce the issue: > # Navigate to localhost:8983/solr > # Select core from dropdown (i have only one core) > # Click on Query or Schema or Documents etc. > # It removes the selected core from dropdown and does not navigate to the > requested page. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9313) Analyzer for Serbian language based on Snowball stemmer
[ https://issues.apache.org/jira/browse/LUCENE-9313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Ivanovic updated LUCENE-9313: Attachment: LUCENE-9313.patch > Analyzer for Serbian language based on Snowball stemmer > --- > > Key: LUCENE-9313 > URL: https://issues.apache.org/jira/browse/LUCENE-9313 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Dragan Ivanovic >Priority: Major > Attachments: LUCENE-9313.patch > > > My colleague and myself developed snowball stemmer for Serbian language > recently: > [https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sbl|https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sb] > > [https://snowballstem.org/algorithms/serbian/stemmer.html] > We have a Serbian Lucene analyzer developed on top of that stemmer, and we > would like to make a contribution to Lucene. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9313) Analyzer for Serbian language based on Snowball stemmer
[ https://issues.apache.org/jira/browse/LUCENE-9313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dragan Ivanovic updated LUCENE-9313: Status: Patch Available (was: Open) > Analyzer for Serbian language based on Snowball stemmer > --- > > Key: LUCENE-9313 > URL: https://issues.apache.org/jira/browse/LUCENE-9313 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Dragan Ivanovic >Priority: Major > Attachments: LUCENE-9313.patch > > > My colleague and myself developed snowball stemmer for Serbian language > recently: > [https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sbl|https://github.com/snowballstem/snowball/blob/master/algorithms/serbian.sb] > > [https://snowballstem.org/algorithms/serbian/stemmer.html] > We have a Serbian Lucene analyzer developed on top of that stemmer, and we > would like to make a contribution to Lucene. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on pull request #1771: SOLR-14752: Fix zk status with prometheus enabled zookeeper
janhoy commented on pull request #1771:
URL: https://github.com/apache/lucene-solr/pull/1771#issuecomment-678276659
Thanks. Please ad a test as well that proves the fix works, e.g. something
like this
```
Index:
solr/core/src/test/org/apache/solr/handler/admin/ZookeeperStatusHandlerTest.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
---
solr/core/src/test/org/apache/solr/handler/admin/ZookeeperStatusHandlerTest.java
(revision 2b2b9e71d3defe6aa4578f9a571078de8b88c7c6)
+++
solr/core/src/test/org/apache/solr/handler/admin/ZookeeperStatusHandlerTest.java
(date 1598014320557)
@@ -184,9 +184,9 @@
when(zkStatusHandler.getZkRawResponse("zoo1:2181",
"ruok")).thenReturn(Arrays.asList("imok"));
when(zkStatusHandler.getZkRawResponse("zoo1:2181", "mntr")).thenReturn(
Arrays.asList("zk_version\t3.5.5-390fe37ea45dee01bf87dc1c042b5e3dcce88653,
built on 05/03/2019 12:07 GMT",
-"zk_avg_latency\t1",
+"zk_avg_latency\t1.0",
"zk_server_state\tleader",
-"zk_synced_followers\t2"));
+"zk_synced_followers\t2.0"));
when(zkStatusHandler.getZkRawResponse("zoo1:2181", "conf")).thenReturn(
Arrays.asList("clientPort=2181"));
when(zkStatusHandler.getZkStatus(anyString(),
any())).thenCallRealMethod();
```
Can you also add a line to solr/CHANGES.txt for Solr 8.7?
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on pull request #1769: SOLR-11245: Absorb the docker-solr repo.
madrob commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-678301517 > I'd be happy to copy exactly from the repo and make the small changes in a different PR, if that would make y'all more comfortable. Doesn't have to be a different PR but would be very helpful to have the unaltered copy as one commit, and then all of your changes as separate commits on top of that. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on pull request #1769: SOLR-11245: Absorb the docker-solr repo.
madrob commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-678301827 Also, I imagine @chatman is interested in 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9473) TestIndexWriterDelete#testDeleteAllNoDeadLock fails sometimes on nightly
Simon Willnauer created LUCENE-9473:
---
Summary: TestIndexWriterDelete#testDeleteAllNoDeadLock fails
sometimes on nightly
Key: LUCENE-9473
URL: https://issues.apache.org/jira/browse/LUCENE-9473
Project: Lucene - Core
Issue Type: Test
Reporter: Simon Willnauer
{noformat}
2> NOTE: reproduce with: ant test -Dtestcase=TestIndexWriterDelete
-Dtests.method=testDeleteAllNoDeadLock -Dtests.seed=E595F5BCCD45156B
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true
-Dtests.linedocsfile=/l/simon/lucene/test-framework/src/resources/org/apache/lucene/util/2000mb.txt.gz
-Dtests.locale=da-DK -Dtests.timezone=SST -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
2> aug. 19, 2020 8:24:20 PM
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
uncaughtException
2> WARNING: Uncaught exception in thread:
Thread[Thread-8,5,TGRP-TestIndexWriterDelete]
2> java.lang.RuntimeException:
org.apache.lucene.store.AlreadyClosedException: this DocumentsWriter is closed
2>at __randomizedtesting.SeedInfo.seed([E595F5BCCD45156B]:0)
2>at
org.apache.lucene.index.TestIndexWriterDelete$1.run(TestIndexWriterDelete.java:332)
2> Caused by: org.apache.lucene.store.AlreadyClosedException: this
DocumentsWriter is closed
2>at
org.apache.lucene.index.DocumentsWriter.ensureOpen(DocumentsWriter.java:202)
2>at
org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:416)
2>at
org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1470)
2>at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1756)
2>at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1399)
2>at
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:193)
2>at
org.apache.lucene.index.TestIndexWriterDelete$1.run(TestIndexWriterDelete.java:326)
2>
2> aug. 19, 2020 8:24:20 PM
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
uncaughtException
2> WARNING: Uncaught exception in thread:
Thread[Thread-7,5,TGRP-TestIndexWriterDelete]
2> java.lang.RuntimeException:
org.apache.lucene.store.AlreadyClosedException: DWPTPool is already closed
2>at __randomizedtesting.SeedInfo.seed([E595F5BCCD45156B]:0)
2>at
org.apache.lucene.index.TestIndexWriterDelete$1.run(TestIndexWriterDelete.java:332)
2> Caused by: org.apache.lucene.store.AlreadyClosedException: DWPTPool is
already closed
2>at
org.apache.lucene.index.DocumentsWriterPerThreadPool.ensureOpen(DocumentsWriterPerThreadPool.java:134)
2>at
org.apache.lucene.index.DocumentsWriterPerThreadPool.newWriter(DocumentsWriterPerThreadPool.java:102)
2>at
org.apache.lucene.index.DocumentsWriterPerThreadPool.getAndLock(DocumentsWriterPerThreadPool.java:128)
2>at
org.apache.lucene.index.DocumentsWriterFlushControl.obtainAndLock(DocumentsWriterFlushControl.java:445)
2>at
org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:409)
2>at
org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1470)
2>at
org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1443)
2>at
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:163)
2>at
org.apache.lucene.index.TestIndexWriterDelete$1.run(TestIndexWriterDelete.java:326)
2>
2> aug. 19, 2020 8:24:20 PM
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
uncaughtException
2> WARNING: Uncaught exception in thread: Thread[Lucene Merge Thread
#9,5,TGRP-TestIndexWriterDelete]
2> org.apache.lucene.index.MergePolicy$MergeException:
org.apache.lucene.index.CorruptIndexException: Problem reading index.
(resource=_di.cfe)
2>at __randomizedtesting.SeedInfo.seed([E595F5BCCD45156B]:0)
2>at
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:703)
2>at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:694)
2> Caused by: org.apache.lucene.index.CorruptIndexException: Problem reading
index. (resource=_di.cfe)
2>at
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:144)
2>at org.apache.lucene.index.SegmentReader.(SegmentReader.java:83)
2>at
org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:171)
2>at
org.apache.lucene.index.ReadersAndUpdates.getReaderForMerge(ReadersAndUpdates.java:714)
2>at
org.apache.lucene.index.IndexWriter.lambda$mergeMiddle$16(IndexWriter.java:4672)
2>at
org.apache.lucene.index.MergePolicy$OneMerge.initMergeReaders(MergePolicy.java:438)
2>at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4669)
2>at org.apache.lucene.index.IndexWriter.merge(Inde
[GitHub] [lucene-solr] s1monw opened a new pull request #1772: LUCENE-9473: Ensure merges are stopped during abort merges
s1monw opened a new pull request #1772: URL: https://github.com/apache/lucene-solr/pull/1772 We need to disable merges while we wait for running merges since IW calls timed wait on it's lock that releases the monitor for the time being which allows new merges to be registered unless we disable them. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14765) optimize DocList creation by skipping sort for sort-irrelevant cases
[
https://issues.apache.org/jira/browse/SOLR-14765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated SOLR-14765:
-
Environment:
I've encountered this problem before in production and have had to come up with
various workarounds for it, so I am super happy to see somebody addressing the
underlying issue here! Bumping Priority to Major, since I think this is far
more beneficial than "Minor" would imply. Please add a CHANGES entry as well.
I looked at the PR and didn't quite understand what was going on well enough to
comment or review, but I am super excited about the advertised results!
Priority: Major (was: Minor)
> optimize DocList creation by skipping sort for sort-irrelevant cases
>
>
> Key: SOLR-14765
> URL: https://issues.apache.org/jira/browse/SOLR-14765
> Project: Solr
> Issue Type: Improvement
>Affects Versions: master (9.0)
> Environment: I've encountered this problem before in production and
> have had to come up with various workarounds for it, so I am super happy to
> see somebody addressing the underlying issue here! Bumping Priority to Major,
> since I think this is far more beneficial than "Minor" would imply. Please
> add a CHANGES entry as well.
> I looked at the PR and didn't quite understand what was going on well enough
> to comment or review, but I am super excited about the advertised results!
>Reporter: Michael Gibney
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{rows=0}}, and for {{MatchAllDocsQuery}} and {{ConstantScoreQuery}}
> (and possibly others?), it is possible for
> {{SolrIndexSearcher.getDocListC(QueryResult, QueryCommand)}} to create a
> DocList directly from {{filterCache}} DocSets -- similar to
> {{useFilterForSortedQuery}}, but without actually sorting.
> This results in significant benefits for high-recall domains, including the
> common (and commonly-cached) use-case of {{q=\*:*}} and {{fq}}, facets, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14765) optimize DocList creation by skipping sort for sort-irrelevant cases
[
https://issues.apache.org/jira/browse/SOLR-14765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated SOLR-14765:
-
Environment: (was: I've encountered this problem before in production
and have had to come up with various workarounds for it, so I am super happy to
see somebody addressing the underlying issue here! Bumping Priority to Major,
since I think this is far more beneficial than "Minor" would imply. Please add
a CHANGES entry as well.
I looked at the PR and didn't quite understand what was going on well enough to
comment or review, but I am super excited about the advertised results!)
I've encountered this problem before in production and have had to come up with
various workarounds for it, so I am super happy to see somebody addressing the
underlying issue here! Bumping Priority to Major, since I think this is far
more beneficial than "Minor" would imply. Please add a CHANGES entry as well.
I looked at the PR and didn't quite understand what was going on well enough to
comment or review, but I am super excited about the advertised results!
> optimize DocList creation by skipping sort for sort-irrelevant cases
>
>
> Key: SOLR-14765
> URL: https://issues.apache.org/jira/browse/SOLR-14765
> Project: Solr
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Michael Gibney
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{rows=0}}, and for {{MatchAllDocsQuery}} and {{ConstantScoreQuery}}
> (and possibly others?), it is possible for
> {{SolrIndexSearcher.getDocListC(QueryResult, QueryCommand)}} to create a
> DocList directly from {{filterCache}} DocSets -- similar to
> {{useFilterForSortedQuery}}, but without actually sorting.
> This results in significant benefits for high-recall domains, including the
> common (and commonly-cached) use-case of {{q=\*:*}} and {{fq}}, facets, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] s1monw commented on pull request #1623: LUCENE-8962: Merge segments on getReader
s1monw commented on pull request #1623: URL: https://github.com/apache/lucene-solr/pull/1623#issuecomment-678311047 @mikemccand I think we are ready here WDYT? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14770) Multiple CoreContainers register same JVM gauge in metrics
[ https://issues.apache.org/jira/browse/SOLR-14770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob reassigned SOLR-14770: Assignee: Mike Drob > Multiple CoreContainers register same JVM gauge in metrics > -- > > Key: SOLR-14770 > URL: https://issues.apache.org/jira/browse/SOLR-14770 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > > Follow on to SOLR-14274, we fixed registering the metric sets, but didn't > change registering the metrics gauges at all. There's a bit more performance > that we can squeeze out of this stone. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14770) Multiple CoreContainers register same JVM gauge in metrics
Mike Drob created SOLR-14770: Summary: Multiple CoreContainers register same JVM gauge in metrics Key: SOLR-14770 URL: https://issues.apache.org/jira/browse/SOLR-14770 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Mike Drob Follow on to SOLR-14274, we fixed registering the metric sets, but didn't change registering the metrics gauges at all. There's a bit more performance that we can squeeze out of this stone. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9470) TestXYMultiPolygonShapeQueries reproducing failure
[
https://issues.apache.org/jira/browse/LUCENE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181921#comment-17181921
]
Simon Willnauer commented on LUCENE-9470:
-
I found another one on our CI:
{noformat}2:13:29[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestXYMultiPolygonShapeQueries -Dtests.method=testRandomBig
-Dtests.seed=8B7FC18414411131 -Dtests.nightly=true -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=en-MU -Dtests.timezone=America/Havana
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
12:13:29[junit4] FAILURE 128s J2 |
TestXYMultiPolygonShapeQueries.testRandomBig <<<
12:13:29[junit4]> Throwable #1: java.lang.AssertionError: wrong hit
(first of possibly more):
12:13:29[junit4]> FAIL: id=6812 should match but did not
12:13:29[junit4]> relation=CONTAINS
{noformat}
> TestXYMultiPolygonShapeQueries reproducing failure
> --
>
> Key: LUCENE-9470
> URL: https://issues.apache.org/jira/browse/LUCENE-9470
> Project: Lucene - Core
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Michael McCandless
>Priority: Major
>
> I hit this while beasting tests against [~simonw]'s PR to add "merge segments
> during getReader":
> It reproduces for me on current
> ({{77a4d495cc553ec80001346376fd87d6b73a6059}}) mainline:
> {noformat}
> [junit4:pickseed] Seed property 'tests.seed' already defined:
> 50C3891F4E0641A4
> [junit4] says g'day! Master seed: 50C3891F4E0641A4
> [junit4] Executing 1 suite with 1 JVM.
> [junit4]
> [junit4] Started J0 PID(1993475@localhost).
> [junit4] Suite: org.apache.lucene.document.TestXYMultiPolygonShapeQueries
> [junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestXYMultiPolygonShapeQueries -Dtests.method=testRandomBig
> -Dtests.seed=50C3891F4E0641A4 -Dtests.nightly=true -Dtests.slow=true
> -Dtests.badap\
> ples=true
> -Dtests.linedocsfile=/l/simon/lucene/test-framework/src/resources/org/apache/lucene/util/2000mb.txt.gz
> -Dtests.locale=en-IM -Dtests.timezone=America/Lima -Dtests.asserts=true
> -Dtests.file.enco\
> ding=UTF-8
> [junit4] FAILURE 51.3s | TestXYMultiPolygonShapeQueries.testRandomBig <<<
> [junit4] > Throwable #1: java.lang.AssertionError: wrong hit (first of
> possibly more):
> [junit4] > FAIL: id=8233 should match but did not
> [junit4] > relation=CONTAINS
> [junit4] > query=XYShapeQuery: field=shape:[XYLINE([3.402823E38,
> 3.4028235E38][3.402823E38, 3.4028235E38][3.402823E38,
> 3.4028235E38][3.402823E38, 3.4028235E38][3.402823E38, 3.4028235E38][3.40282\
> 3E38, 3.4028235E38][3.402823E38, 3.4028235E38][3.402823E38,
> 3.4028235E38][3.402823E38, 3.4028235E38][3.402823E38,
> 3.4028235E38][3.402823E38, 3.4028235E38][3.402823E38,
> 3.4028235E38][3.402823E38, 3.40282\
> 35E38][3.402823E38, 3.4028235E38][3.402823E38, 3.4028235E38][3.402823E38,
> 3.4028235E38][3.402823E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38, 3.4028235E38][3.4\
> 028229E38, 3.4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229\
> E38, 3.4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229E38, 3\
> .4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229E38, 3.40282\
> 35E38][3.4028229E38, 3.4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229E38, 3.4028235E38][3.4028229E38,
> 3.4028235E38][3.4028229E38, 3.4028233E38][3.4028229E38, 3.4028233E38]\
> [3.4028229E38, 3.4028233E38][3.4028229E38, 3.4028233E38][3.4028229E38,
> 3.4028233E38][3.4028229E38, 3.4028233E38][3.4028229E38,
> 3.4028233E38][3.4028229E38, 3.4028233E38][3.4028229E38, 3.4028233E38][3.402\
> 8227E38, 3.4028233E38][3.4028227E38, 3.4028233E38][3.4028227E38,
> 3.4028233E38][3.4028227E38, 3.4028233E38][3.4028227E38,
> 3.4028233E38][3.4028227E38, 3.4028233E38][3.4028227E38,
> 3.4028233E38][3.4028227E3\
> 8, 3.4028233E38][3.4028227E38, 3.4028233E38][3.4028227E38,
> 3.4028233E38][3.4028227E38, 3.4028233E38][3.4028227E38,
> 3.4028233E38][3.4028227E38, 3.4028233E38][3.4028227E38,
> 3.4028233E38][3.4028227E38, 3.4\
> 028233E38][3.4028227E38, 3.4028233E38][3.4028227E38,
> 3.4028233E38][3.4028227E38, 3.4028233E38][3.4028227E38,
> 3.4028233E38][3.4028227E38, 3.4028233E38][3.4028227E38,
> 3.4028233E38][3.4028227E38, 3.4028233\
> ...
> 3E38][3.4028235E38, 3.4028233E38][3.4028235E38, 3.4028233E38][3
[jira] [Commented] (SOLR-14770) Multiple CoreContainers register same JVM gauge in metrics
[ https://issues.apache.org/jira/browse/SOLR-14770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181932#comment-17181932 ] Mike Drob commented on SOLR-14770: -- [~ab] I just updated [https://github.com/apache/lucene-solr/pull/1469] with rebased changes, if you wanted to take a look. Otherwise I'll merge early next week. > Multiple CoreContainers register same JVM gauge in metrics > -- > > Key: SOLR-14770 > URL: https://issues.apache.org/jira/browse/SOLR-14770 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > > Follow on to SOLR-14274, we fixed registering the metric sets, but didn't > change registering the metrics gauges at all. There's a bit more performance > that we can squeeze out of this stone. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14750) Harden TestBulkSchemaConcurrent
[ https://issues.apache.org/jira/browse/SOLR-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181945#comment-17181945 ] Erick Erickson commented on SOLR-14750: --- [~noble.paul] Can we close this now? > Harden TestBulkSchemaConcurrent > --- > > Key: SOLR-14750 > URL: https://issues.apache.org/jira/browse/SOLR-14750 > Project: Solr > Issue Type: Improvement > Components: Tests >Reporter: Erick Erickson >Assignee: Noble Paul >Priority: Major > Attachments: SOLR-14750.patch > > Time Spent: 1h > Remaining Estimate: 0h > > This test has been failing quite often lately. I poked around a bit and see > what I _think_ is evidence of a race condition in CoreContainer.reload where > a reload on the same core is happening from two places in close succession. > I'll attach a preliminary patch soon. > Without this patch I had 25 failures out of 1,000 runs, with it 0. > I consider this patch a WIP, putting up for comment. Well, it has nocommits > so... But In particular, I have to review some changes I made about which > name we're using for PendingCoreOps. I also want to back out my changes and > beast it again with some more logging to see if I can nail down that multiple > reloads are happening before declaring victory. > What this does is put the name of the core we're reloading in pendingCoreOps > earlier in the reload process. Then the second call to reload will wait until > the first is completed. I also restructured it a bit because I don't like if > clauses that go on forever and a small else clause way down the code. I > inverted the test and bailed out of the method rather than fall off the end > after the else clause. > One thing I don't like about this is two reloads in such rapid succession > seems wasteful. Even so, I can imagine that one reload gets through far > enough to load the schema, then a schema update changes the schema _then_ > calls reload. So I don't think just returning if there's a reload happening > on that core already is valid. > More to come. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson closed pull request #1685: LUCENE-9433: Remove Ant support from trunk
ErickErickson closed pull request #1685: URL: https://github.com/apache/lucene-solr/pull/1685 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] slackhappy commented on a change in pull request #1436: SOLR-14413: allow timeAllowed and cursorMark parameters
slackhappy commented on a change in pull request #1436: URL: https://github.com/apache/lucene-solr/pull/1436#discussion_r47487 ## File path: solr/solr-ref-guide/src/common-query-parameters.adoc ## @@ -206,7 +206,7 @@ The default value of this parameter is blank, which causes no extra "explain inf == timeAllowed Parameter -This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <> counts, and result <> may not be accurate for the entire result set. In case of expiration, if `omitHeader` isn't set to `true` the response header contains a special flag called `partialResults`. +This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <> counts, and result <> may not be accurate for the entire result set. In case of expiration, if `omitHeader` isn't set to `true` the response header contains a special flag called `partialResults`. When using `timeAllowed` in combination with <>, and the `partialResults` flag is present, `cursorMark` can match `nextCursorMark` even if there may be more results. Review 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] slackhappy commented on a change in pull request #1436: SOLR-14413: allow timeAllowed and cursorMark parameters
slackhappy commented on a change in pull request #1436: URL: https://github.com/apache/lucene-solr/pull/1436#discussion_r474778543 ## File path: solr/solr-ref-guide/src/common-query-parameters.adoc ## @@ -206,7 +206,7 @@ The default value of this parameter is blank, which causes no extra "explain inf == timeAllowed Parameter -This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <> counts, and result <> may not be accurate for the entire result set. In case of expiration, if `omitHeader` isn't set to `true` the response header contains a special flag called `partialResults`. +This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <> counts, and result <> may not be accurate for the entire result set. In case of expiration, if `omitHeader` isn't set to `true` the response header contains a special flag called `partialResults`. When using `timeAllowed` in combination with <>, and the `partialResults` flag is present, `cursorMark` can match `nextCursorMark` even if there may be more results. Review 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] slackhappy commented on a change in pull request #1436: SOLR-14413: allow timeAllowed and cursorMark parameters
slackhappy commented on a change in pull request #1436:
URL: https://github.com/apache/lucene-solr/pull/1436#discussion_r474780615
##
File path: solr/core/src/test/org/apache/solr/CursorPagingTest.java
##
@@ -499,6 +492,61 @@ public void testSimple() throws Exception {
));
}
+ /**
+ * test that timeAllowed parameter can be used with cursors
+ * uses DelayingSearchComponent in solrconfig-deeppaging.xml
+ */
+ public void testTimeAllowed() throws Exception {
+String wontExceedTimeout = "1";
+int numDocs = 100;
+// Create a bunch of docs, inspired by createIndex in
ExitableDirectoryReaderTest
+for (int i = 0; i < numDocs; i++) {
+ assertU(adoc("id", Integer.toString(i), "name", "a" + i + " b" + i + "
c" + i + " d"+i + " e" + i));
Review comment:
I ended up keeping my own docs generation routine, because I wanted to
do a little more with it:
1. more than 100 docs [Bram's
patch](https://issues.apache.org/jira/secure/attachment/13010039/SOLR-14413-bram.patch)
used 1000, so I decided to use the same.
1. generate an expected set of ids at the same time, so that I could confirm
all results were paged through
1. randomize the id insert order
I took your advice about simplifying the name field.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] slackhappy commented on a change in pull request #1436: SOLR-14413: allow timeAllowed and cursorMark parameters
slackhappy commented on a change in pull request #1436: URL: https://github.com/apache/lucene-solr/pull/1436#discussion_r474794540 ## File path: solr/solr-ref-guide/src/common-query-parameters.adoc ## @@ -206,7 +206,7 @@ The default value of this parameter is blank, which causes no extra "explain inf == timeAllowed Parameter -This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <> counts, and result <> may not be accurate for the entire result set. In case of expiration, if `omitHeader` isn't set to `true` the response header contains a special flag called `partialResults`. +This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <>, <> counts, and result <> may not be accurate for the entire result set. In case of expiration, if `omitHeader` isn't set to `true` the response header contains a special flag called `partialResults`. Review comment: I added a notice to `omitHeader` ## File path: solr/solr-ref-guide/src/common-query-parameters.adoc ## @@ -252,7 +252,7 @@ The default value of this parameter is `false`. This parameter may be set to either `true` or `false`. -If set to `true`, this parameter excludes the header from the returned results. The header contains information about the request, such as the time it took to complete. The default value for this parameter is `false`. +If set to `true`, this parameter excludes the header from the returned results. The header contains information about the request, such as the time it took to complete. The default value for this parameter is `false`. When using parameters such as <>, and <>, which can lead to partial results, it is advisable to keep the keep the header, so that the `partialResults` flag can be checked, and values such as `numFound`, `nextCursorMark`, <> counts, and result <> can be interpreted in the context of partial results. Review comment: https://user-images.githubusercontent.com/685141/90911861-98c03b80-e3a7-11ea-910a-d1f9d8d266f6.png";> 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] slackhappy commented on a change in pull request #1436: SOLR-14413: allow timeAllowed and cursorMark parameters
slackhappy commented on a change in pull request #1436: URL: https://github.com/apache/lucene-solr/pull/1436#discussion_r474794540 ## File path: solr/solr-ref-guide/src/common-query-parameters.adoc ## @@ -206,7 +206,7 @@ The default value of this parameter is blank, which causes no extra "explain inf == timeAllowed Parameter -This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <> counts, and result <> may not be accurate for the entire result set. In case of expiration, if `omitHeader` isn't set to `true` the response header contains a special flag called `partialResults`. +This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <>, <> counts, and result <> may not be accurate for the entire result set. In case of expiration, if `omitHeader` isn't set to `true` the response header contains a special flag called `partialResults`. Review comment: I added a notice to `omitHeader`, (WAND == segmentTerminateEarly?) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] rishisankar commented on a change in pull request #1770: SOLR-14763 SolrJ HTTP/2 Async API using CompletableFuture
rishisankar commented on a change in pull request #1770:
URL: https://github.com/apache/lucene-solr/pull/1770#discussion_r474810544
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseCloudSolrClient.java
##
@@ -853,6 +858,18 @@ public RouteException(ErrorCode errorCode,
NamedList throwables, Map<
@Override
public NamedList request(@SuppressWarnings({"rawtypes"})SolrRequest
request, String collection) throws SolrServerException, IOException {
+ // synchronous requests should return an already completed future
+ return getNowOrException(makeRequest(request, collection, false));
+ }
+
+ CompletableFuture> makeRequest(SolrRequest request,
+ String collection,
+ boolean isAsyncRequest)
throws SolrServerException, IOException {
+if (isAsyncRequest && !(getLbClient() instanceof LBHttp2SolrClient)) {
+ log.warn("Asynchronous requests require HTTP/2 SolrJ client, defaulting
to synchronous request.");
+ isAsyncRequest = false;
Review comment:
The reason I included this check was because I later cast
`(LBHttp2SolrClient)getLbClient()` (in sendRequest) - so even without this
check, custom LB client implementations wouldn't work unless they subclass
LBHttp2SolrClient. Perhaps another approach is to add an abstract asyncRequest
method to LBSolrClient (which both `LBHttpSolrClient` and `LBHttp2SolrClient`
extend) and just call that instead - and throw an
`UnsupportedOperationException` in the case of the HTTP/1 client for now. What
do you think?
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman commented on pull request #1769: SOLR-11245: Absorb the docker-solr repo.
HoustonPutman commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-678386899 > > I'd be happy to copy exactly from the repo and make the small changes in a different PR, if that would make y'all more comfortable. > > Doesn't have to be a different PR but would be very helpful to have the unaltered copy as one commit, and then all of your changes as separate commits on top of that. I'll try to make this happen. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] rishisankar commented on a change in pull request #1770: SOLR-14763 SolrJ HTTP/2 Async API using CompletableFuture
rishisankar commented on a change in pull request #1770:
URL: https://github.com/apache/lucene-solr/pull/1770#discussion_r474823050
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java
##
@@ -394,26 +393,26 @@ public void onHeaders(Response response) {
assert ObjectReleaseTracker.track(is);
try {
NamedList body = processErrorsAndResponse(solrRequest,
parser, response, is);
-asyncListener.onSuccess(body);
- } catch (RemoteSolrException e) {
-if (SolrException.getRootCause(e) != CANCELLED_EXCEPTION) {
- asyncListener.onFailure(e);
-}
- } catch (SolrServerException e) {
-asyncListener.onFailure(e);
+future.complete(body);
+ } catch (RemoteSolrException | SolrServerException e) {
+future.completeExceptionally(e);
}
});
}
@Override
public void onFailure(Response response, Throwable failure) {
super.onFailure(response, failure);
-if (failure != CANCELLED_EXCEPTION) {
- asyncListener.onFailure(new
SolrServerException(failure.getMessage(), failure));
-}
+future.completeExceptionally(new
SolrServerException(failure.getMessage(), failure));
}
});
-return () -> req.abort(CANCELLED_EXCEPTION);
+future.exceptionally((error) -> {
+ if (error instanceof CancellationException) {
+req.abort(new Exception());
Review comment:
> * Why do an instanceof check on "error" at all; why not simply always
req.abort(error)?
> * Why create a new Exception when we already have a suitable Throwable
type in variable "error"?
Yes I think you're right, the instanceof check and new Exception seem
unneccessary - will change that
> I see your point, but I in this case from CompletableFuture perspective,
it get called with `cancel()` first then `completeExceptionally` will that mess
up with internal state of the future instance?
Hmm I may be misunderstanding the question but I don't think so - the
`future.exceptionally` is a hook that would run after the future is already
marked as completed due to an exception, so subsequent calls to
`completeExceptionally` shouldn't do anything. From CF javadoc, "When two or
more threads attempt to complete, completeExceptionally, or cancel a
CompletableFuture, only one of them succeeds."
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] rishisankar commented on a change in pull request #1770: SOLR-14763 SolrJ HTTP/2 Async API using CompletableFuture
rishisankar commented on a change in pull request #1770:
URL: https://github.com/apache/lucene-solr/pull/1770#discussion_r474823357
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java
##
@@ -394,26 +393,26 @@ public void onHeaders(Response response) {
assert ObjectReleaseTracker.track(is);
try {
NamedList body = processErrorsAndResponse(solrRequest,
parser, response, is);
-asyncListener.onSuccess(body);
- } catch (RemoteSolrException e) {
-if (SolrException.getRootCause(e) != CANCELLED_EXCEPTION) {
- asyncListener.onFailure(e);
-}
- } catch (SolrServerException e) {
-asyncListener.onFailure(e);
+future.complete(body);
+ } catch (RemoteSolrException | SolrServerException e) {
+future.completeExceptionally(e);
}
});
}
@Override
public void onFailure(Response response, Throwable failure) {
super.onFailure(response, failure);
-if (failure != CANCELLED_EXCEPTION) {
- asyncListener.onFailure(new
SolrServerException(failure.getMessage(), failure));
-}
+future.completeExceptionally(new
SolrServerException(failure.getMessage(), failure));
}
});
-return () -> req.abort(CANCELLED_EXCEPTION);
+future.exceptionally((error) -> {
+ if (error instanceof CancellationException) {
+req.abort(new Exception());
Review comment:
> * Why do an instanceof check on "error" at all; why not simply always
req.abort(error)?
> * Why create a new Exception when we already have a suitable Throwable
type in variable "error"?
Yes I think you're right, the instanceof check and new Exception seem
unneccessary - will change that
> I see your point, but I in this case from CompletableFuture perspective,
it get called with `cancel()` first then `completeExceptionally` will that mess
up with internal state of the future instance?
Hmm I don't think so - the `future.exceptionally` is a hook that would run
after the future is already marked as completed due to an exception, so
subsequent calls to `completeExceptionally` shouldn't do anything. From CF
javadoc, "When two or more threads attempt to complete, completeExceptionally,
or cancel a CompletableFuture, only one of them succeeds."
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman commented on pull request #1769: SOLR-11245: Absorb the docker-solr repo.
HoustonPutman commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-678403695 @madrob The first commit has the Dockerfile, tests, scripts and docs copied over from the docker-solr repo. The rest of the commits are small changes to the scripts, splitting the dockerfile logic into two parts, and adding the gradle logic. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14765) optimize DocList creation by skipping sort for sort-irrelevant cases
[
https://issues.apache.org/jira/browse/SOLR-14765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182037#comment-17182037
]
Michael Gibney commented on SOLR-14765:
---
Thanks, [~mdrob]! I just added a CHANGES.txt entry. I'll also explicitly call
out that there are some {{nocommit}} comments in the code. Most of these are
questions about how to handle some of the "whitebox" test assumptions about
how/when caching is expected to work. {{ExitableDirectoryReaderTest}} tests
cache hit assumptions in ways that can (newly?) crosstalk between different
tests, but other than that I would propose either updating code to accommodate
new behavior, or leaving the current workarounds in place (effectively
disabling the new optimization) and adding some additional lines to check the
new "optimized" behavior.
The other {{nocommit}} marks where this optimization is disabled for the
{{cursorMark}} case. I'm inclined to just leave that as-is (optimization
disabled for {{cursorMark}}) but in principle I think there might be a way to
enable the optimization even in the {{cursorMark}} case?
As far as the "safety" of this commit affecting such a central codepath, it's
kind of a double-edged sword: on the one hand, I think it should be covered
well by existing tests across the test suite (all of which pass); on the other
hand (wrt peformance), because it has the potential to affect cache usage
patterns, we should probably tread carefully and think through the possible
negative consequences for some use patterns. (That said, for the majority of
use patterns I think there would be essentially _no_ change, and for the
majority of _affected_ use patterns I think change would be significantly
positive ...)
> optimize DocList creation by skipping sort for sort-irrelevant cases
>
>
> Key: SOLR-14765
> URL: https://issues.apache.org/jira/browse/SOLR-14765
> Project: Solr
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Michael Gibney
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{rows=0}}, and for {{MatchAllDocsQuery}} and {{ConstantScoreQuery}}
> (and possibly others?), it is possible for
> {{SolrIndexSearcher.getDocListC(QueryResult, QueryCommand)}} to create a
> DocList directly from {{filterCache}} DocSets -- similar to
> {{useFilterForSortedQuery}}, but without actually sorting.
> This results in significant benefits for high-recall domains, including the
> common (and commonly-cached) use-case of {{q=\*:*}} and {{fq}}, facets, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] rishisankar commented on a change in pull request #1770: SOLR-14763 SolrJ HTTP/2 Async API using CompletableFuture
rishisankar commented on a change in pull request #1770:
URL: https://github.com/apache/lucene-solr/pull/1770#discussion_r474836063
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseCloudSolrClient.java
##
@@ -1167,8 +1191,38 @@ public RouteException(ErrorCode errorCode,
NamedList throwables, Map<
}
LBSolrClient.Req req = new LBSolrClient.Req(request, theUrlList);
-LBSolrClient.Rsp rsp = getLbClient().request(req);
-return rsp.getResponse();
+if (isAsyncRequest) {
+ CompletableFuture lbFuture = ((LBHttp2SolrClient)
getLbClient()).requestAsync(req);
Review comment:
I agree -- added a quick documentation comment of this on the
makeRequest method.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on a change in pull request #1759: SOLR-13438: on collection delete, also delete .AUTOCREATED config set
madrob commented on a change in pull request #1759:
URL: https://github.com/apache/lucene-solr/pull/1759#discussion_r474835389
##
File path:
solr/core/src/test/org/apache/solr/cloud/api/collections/SimpleCollectionCreateDeleteTest.java
##
@@ -32,69 +28,151 @@
import org.apache.solr.util.TimeOut;
import org.junit.Test;
+import java.util.Collection;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.TimeoutException;
+
public class SimpleCollectionCreateDeleteTest extends
AbstractFullDistribZkTestBase {
- public SimpleCollectionCreateDeleteTest() {
-sliceCount = 1;
- }
-
- @Test
- @ShardsFixed(num = 1)
- public void test() throws Exception {
-String overseerNode =
OverseerCollectionConfigSetProcessor.getLeaderNode(cloudClient.getZkStateReader().getZkClient());
-String notOverseerNode = null;
-for (CloudJettyRunner cloudJetty : cloudJettys) {
- if (!overseerNode.equals(cloudJetty.nodeName)) {
-notOverseerNode = cloudJetty.nodeName;
-break;
- }
+public SimpleCollectionCreateDeleteTest() {
+sliceCount = 1;
}
-String collectionName = "SimpleCollectionCreateDeleteTest";
-CollectionAdminRequest.Create create =
CollectionAdminRequest.createCollection(collectionName,1,1)
-.setCreateNodeSet(overseerNode);
-
-NamedList request = create.process(cloudClient).getResponse();
-
-if (request.get("success") != null) {
-
assertTrue(cloudClient.getZkStateReader().getZkClient().exists(ZkStateReader.COLLECTIONS_ZKNODE
+ "/" + collectionName, false));
-
- @SuppressWarnings({"rawtypes"})
- CollectionAdminRequest delete =
CollectionAdminRequest.deleteCollection(collectionName);
- cloudClient.request(delete);
-
-
assertFalse(cloudClient.getZkStateReader().getZkClient().exists(ZkStateReader.COLLECTIONS_ZKNODE
+ "/" + collectionName, false));
-
- // currently, removing a collection does not wait for cores to be
unloaded
- TimeOut timeout = new TimeOut(30, TimeUnit.SECONDS,
TimeSource.NANO_TIME);
- while (true) {
-
-if( timeout.hasTimedOut() ) {
- throw new TimeoutException("Timed out waiting for all collections to
be fully removed.");
+
+@Test
+@ShardsFixed(num = 1)
+public void testCreateAndDeleteThenCreateAgain() throws Exception {
Review 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on pull request #1759: SOLR-13438: on collection delete, also delete .AUTOCREATED config set
madrob commented on pull request #1759: URL: https://github.com/apache/lucene-solr/pull/1759#issuecomment-678409403 I think only committers can retriever the precommit, I launched it again, if it comes back clean will merge 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob edited a comment on pull request #1759: SOLR-13438: on collection delete, also delete .AUTOCREATED config set
madrob edited a comment on pull request #1759: URL: https://github.com/apache/lucene-solr/pull/1759#issuecomment-678409403 I think only committers can re-launch the precommit, I launched it again, if it comes back clean will merge 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14705) Release Smoke Test Script Shows Unusable JDK Version
[ https://issues.apache.org/jira/browse/SOLR-14705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182044#comment-17182044 ] Marcus Eagan commented on SOLR-14705: - Agree > Release Smoke Test Script Shows Unusable JDK Version > > > Key: SOLR-14705 > URL: https://issues.apache.org/jira/browse/SOLR-14705 > Project: Solr > Issue Type: Bug > Components: release-scripts >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Minor > > The script works fine, but the help text in the smoke test script needs to be > replaced. Should be Java 8 for now and moved to Java 11 when the community is > preparing to release Solr 9. :) > Here's the output: > usage: smokeTestRelease.py [-h] [--tmp-dir PATH] [--not-signed] >[--local-keys PATH] [--revision REVISION] >[--version X.Y.Z(-ALPHA|-BETA)?] >[--test-java9 JAVA9_HOME] [--download-only] >url ... > > I wouldn't touch Java 9 with a ten foot pole, and nor should new releases. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] s1monw commented on a change in pull request #1772: LUCENE-9473: Ensure merges are stopped during abort merges
s1monw commented on a change in pull request #1772:
URL: https://github.com/apache/lucene-solr/pull/1772#discussion_r474853999
##
File path: lucene/core/src/java/org/apache/lucene/index/IndexWriter.java
##
@@ -5728,4 +5735,25 @@ public String toString() {
return writer.segString();
}
}
+
+ private class Merges {
+boolean closed = false;
Review comment:
right! thanks that's a leftover
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14413) allow timeAllowed and cursorMark parameters
[
https://issues.apache.org/jira/browse/SOLR-14413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Gallagher updated SOLR-14413:
--
Attachment: image-2020-08-21-14-18-36-229.png
> allow timeAllowed and cursorMark parameters
> ---
>
> Key: SOLR-14413
> URL: https://issues.apache.org/jira/browse/SOLR-14413
> Project: Solr
> Issue Type: Improvement
> Components: search
>Reporter: John Gallagher
>Priority: Minor
> Attachments: SOLR-14413-bram.patch, SOLR-14413-jg-update1.patch,
> SOLR-14413.patch, image-2020-08-18-16-56-41-736.png,
> image-2020-08-18-16-56-59-178.png, image-2020-08-21-14-18-36-229.png,
> timeallowed_cursormarks_results.txt
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Ever since cursorMarks were introduced in SOLR-5463 in 2014, cursorMark and
> timeAllowed parameters were not allowed in combination ("Can not search using
> both cursorMark and timeAllowed")
> , from [QueryComponent.java|#L359]]:
>
> {code:java}
>
> if (null != rb.getCursorMark() && 0 < timeAllowed) {
> // fundamentally incompatible
> throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "Can not
> search using both " + CursorMarkParams.CURSOR_MARK_PARAM + " and " +
> CommonParams.TIME_ALLOWED);
> } {code}
> While theoretically impure to use them in combination, it is often desirable
> to support cursormarks-style deep paging and attempt to protect Solr nodes
> from runaway queries using timeAllowed, in the hopes that most of the time,
> the query completes in the allotted time, and there is no conflict.
>
> However if the query takes too long, it may be preferable to end the query
> and protect the Solr node and provide the user with a somewhat inaccurate
> sorted list. As noted in SOLR-6930, SOLR-5986 and others, timeAllowed is
> frequently used to prevent runaway load. In fact, cursorMark and
> shards.tolerant are allowed in combination, so any argument in favor of
> purity would be a bit muddied in my opinion.
>
> This was discussed once in the mailing list that I can find:
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201506.mbox/%3c5591740b.4080...@elyograg.org%3E]
> It did not look like there was strong support for preventing the combination.
>
> I have tested cursorMark and timeAllowed combination together, and even when
> partial results are returned because the timeAllowed is exceeded, the
> cursorMark response value is still valid and reasonable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14413) allow timeAllowed and cursorMark parameters
[
https://issues.apache.org/jira/browse/SOLR-14413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Gallagher updated SOLR-14413:
--
Attachment: SOLR-14413-jg-update2.patch
> allow timeAllowed and cursorMark parameters
> ---
>
> Key: SOLR-14413
> URL: https://issues.apache.org/jira/browse/SOLR-14413
> Project: Solr
> Issue Type: Improvement
> Components: search
>Reporter: John Gallagher
>Priority: Minor
> Attachments: SOLR-14413-bram.patch, SOLR-14413-jg-update1.patch,
> SOLR-14413-jg-update2.patch, SOLR-14413.patch,
> image-2020-08-18-16-56-41-736.png, image-2020-08-18-16-56-59-178.png,
> image-2020-08-21-14-18-36-229.png, timeallowed_cursormarks_results.txt
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Ever since cursorMarks were introduced in SOLR-5463 in 2014, cursorMark and
> timeAllowed parameters were not allowed in combination ("Can not search using
> both cursorMark and timeAllowed")
> , from [QueryComponent.java|#L359]]:
>
> {code:java}
>
> if (null != rb.getCursorMark() && 0 < timeAllowed) {
> // fundamentally incompatible
> throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "Can not
> search using both " + CursorMarkParams.CURSOR_MARK_PARAM + " and " +
> CommonParams.TIME_ALLOWED);
> } {code}
> While theoretically impure to use them in combination, it is often desirable
> to support cursormarks-style deep paging and attempt to protect Solr nodes
> from runaway queries using timeAllowed, in the hopes that most of the time,
> the query completes in the allotted time, and there is no conflict.
>
> However if the query takes too long, it may be preferable to end the query
> and protect the Solr node and provide the user with a somewhat inaccurate
> sorted list. As noted in SOLR-6930, SOLR-5986 and others, timeAllowed is
> frequently used to prevent runaway load. In fact, cursorMark and
> shards.tolerant are allowed in combination, so any argument in favor of
> purity would be a bit muddied in my opinion.
>
> This was discussed once in the mailing list that I can find:
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201506.mbox/%3c5591740b.4080...@elyograg.org%3E]
> It did not look like there was strong support for preventing the combination.
>
> I have tested cursorMark and timeAllowed combination together, and even when
> partial results are returned because the timeAllowed is exceeded, the
> cursorMark response value is still valid and reasonable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14413) allow timeAllowed and cursorMark parameters
[
https://issues.apache.org/jira/browse/SOLR-14413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182060#comment-17182060
]
John Gallagher commented on SOLR-14413:
---
Thanks [~mdrob] for reviewing!
I added new documentation for omitHeader, advising against omitting when using
parameters that can lead to partial results, because the header flag informs
the interpretation of the result values.
!image-2020-08-21-14-18-36-229.png|width=558,height=180!
I updated timeAllowed documentation as well.
I incorporated [~bvd]'s test idea of generating a result set, running it to
completion, and confirming all documents were found in the correct order, while
also asserting that at least one partialResults event occurred.
I have generated a new patch, SOLR-14413-jg-update2.patch, and updated my PR:
[https://github.com/apache/lucene-solr/pull/1436]
John
> allow timeAllowed and cursorMark parameters
> ---
>
> Key: SOLR-14413
> URL: https://issues.apache.org/jira/browse/SOLR-14413
> Project: Solr
> Issue Type: Improvement
> Components: search
>Reporter: John Gallagher
>Priority: Minor
> Attachments: SOLR-14413-bram.patch, SOLR-14413-jg-update1.patch,
> SOLR-14413.patch, image-2020-08-18-16-56-41-736.png,
> image-2020-08-18-16-56-59-178.png, image-2020-08-21-14-18-36-229.png,
> timeallowed_cursormarks_results.txt
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Ever since cursorMarks were introduced in SOLR-5463 in 2014, cursorMark and
> timeAllowed parameters were not allowed in combination ("Can not search using
> both cursorMark and timeAllowed")
> , from [QueryComponent.java|#L359]]:
>
> {code:java}
>
> if (null != rb.getCursorMark() && 0 < timeAllowed) {
> // fundamentally incompatible
> throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "Can not
> search using both " + CursorMarkParams.CURSOR_MARK_PARAM + " and " +
> CommonParams.TIME_ALLOWED);
> } {code}
> While theoretically impure to use them in combination, it is often desirable
> to support cursormarks-style deep paging and attempt to protect Solr nodes
> from runaway queries using timeAllowed, in the hopes that most of the time,
> the query completes in the allotted time, and there is no conflict.
>
> However if the query takes too long, it may be preferable to end the query
> and protect the Solr node and provide the user with a somewhat inaccurate
> sorted list. As noted in SOLR-6930, SOLR-5986 and others, timeAllowed is
> frequently used to prevent runaway load. In fact, cursorMark and
> shards.tolerant are allowed in combination, so any argument in favor of
> purity would be a bit muddied in my opinion.
>
> This was discussed once in the mailing list that I can find:
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201506.mbox/%3c5591740b.4080...@elyograg.org%3E]
> It did not look like there was strong support for preventing the combination.
>
> I have tested cursorMark and timeAllowed combination together, and even when
> partial results are returned because the timeAllowed is exceeded, the
> cursorMark response value is still valid and reasonable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] thelabdude commented on pull request #1769: SOLR-11245: Absorb the docker-solr repo.
thelabdude commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-678429788 Looking great @HoustonPutman ! I ran `g assemble` and then launched the Docker image using a compose file: ``` version: '3.2' services: zookeeper: image: zookeeper:3.5.8 ports: - "2181:2181" solr: image: apache/solr:9.0.0-SNAPSHOT depends_on: - zookeeper ports: - "8983:8983" environment: SOLR_JETTY_HOST: "0.0.0.0" command: ["solr-foreground", "-z", "zookeeper:2181", "-c"] ``` Note the need to set SOLR_JETTY_HOST to bind to all interfaces in the container if you want to expose Solr to your local workstation. Still kicking the tires but looking great so far. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14765) optimize DocList creation by skipping sort for sort-irrelevant cases
[
https://issues.apache.org/jira/browse/SOLR-14765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182074#comment-17182074
]
Mike Drob commented on SOLR-14765:
--
The explanation of the no commit makes a lot of sense, and clarifies a few
things. That was one of the big questions I had - why do we need to add those
sorts in the test, but the lack of test independence totally answers that.
I think that all of our unit tests should be independent, so maybe that means
that we have to refactor EDRT to use new collections between each test? Or drop
caches (would a soft commit do this?)
Does cursorMark with rows=0 make sense? nextCursorMark will always be equal to
the current cursor, no? So there's no reason to sort at all.
> optimize DocList creation by skipping sort for sort-irrelevant cases
>
>
> Key: SOLR-14765
> URL: https://issues.apache.org/jira/browse/SOLR-14765
> Project: Solr
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Michael Gibney
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{rows=0}}, and for {{MatchAllDocsQuery}} and {{ConstantScoreQuery}}
> (and possibly others?), it is possible for
> {{SolrIndexSearcher.getDocListC(QueryResult, QueryCommand)}} to create a
> DocList directly from {{filterCache}} DocSets -- similar to
> {{useFilterForSortedQuery}}, but without actually sorting.
> This results in significant benefits for high-recall domains, including the
> common (and commonly-cached) use-case of {{q=\*:*}} and {{fq}}, facets, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14765) optimize DocList creation by skipping sort for sort-irrelevant cases
[
https://issues.apache.org/jira/browse/SOLR-14765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182084#comment-17182084
]
Michael Gibney commented on SOLR-14765:
---
Right, that makes sense. For {{cursorMark}} optimization should (as you say) be
possible for "rows=0", but I'm less sure about "sort by score" on
{{MatchAllDocsQuery}} or {{ConstantScoreQuery}}. I think that _can_ be done
with {{cursorMark}} (it would just always fall back to docId sort as a
tiebreaker?); sort would be similarly pointless in this case, but I couldn't
figure out whether it was possible (or worth it -- kind of an edge case) to
respect {{searchAfter}} in conjunction with skipping sort ...
> optimize DocList creation by skipping sort for sort-irrelevant cases
>
>
> Key: SOLR-14765
> URL: https://issues.apache.org/jira/browse/SOLR-14765
> Project: Solr
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Michael Gibney
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{rows=0}}, and for {{MatchAllDocsQuery}} and {{ConstantScoreQuery}}
> (and possibly others?), it is possible for
> {{SolrIndexSearcher.getDocListC(QueryResult, QueryCommand)}} to create a
> DocList directly from {{filterCache}} DocSets -- similar to
> {{useFilterForSortedQuery}}, but without actually sorting.
> This results in significant benefits for high-recall domains, including the
> common (and commonly-cached) use-case of {{q=\*:*}} and {{fq}}, facets, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14771) Reproducible failure for LBDSolrClientTest
Erick Erickson created SOLR-14771: - Summary: Reproducible failure for LBDSolrClientTest Key: SOLR-14771 URL: https://issues.apache.org/jira/browse/SOLR-14771 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Tests Affects Versions: master (9.0) Reporter: Erick Erickson ./gradlew :solr:solrj:test --tests "org.apache.solr.client.solrj.impl.LBSolrClientTest" -Ptests.seed=E6AFE16CC61929A6 -Ptests.file.encoding=US-ASCII -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14772) Reproducible failure TestConfigOverlay
Erick Erickson created SOLR-14772: - Summary: Reproducible failure TestConfigOverlay Key: SOLR-14772 URL: https://issues.apache.org/jira/browse/SOLR-14772 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Tests Reporter: Erick Erickson ./gradlew :solr:core:test --tests "org.apache.solr.core.TestConfigOverlay" -Ptests.seed=E6AFE16CC61929A6 -Ptests.file.encoding=US-ASCII -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14771) Reproducible failure for LBSolrClientTest
[ https://issues.apache.org/jira/browse/SOLR-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-14771: -- Summary: Reproducible failure for LBSolrClientTest (was: Reproducible failure for LBDSolrClientTest) > Reproducible failure for LBSolrClientTest > - > > Key: SOLR-14771 > URL: https://issues.apache.org/jira/browse/SOLR-14771 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Affects Versions: master (9.0) >Reporter: Erick Erickson >Priority: Major > > ./gradlew :solr:solrj:test --tests > "org.apache.solr.client.solrj.impl.LBSolrClientTest" > -Ptests.seed=E6AFE16CC61929A6 -Ptests.file.encoding=US-ASCII -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on pull request #1769: SOLR-11245: Absorb the docker-solr repo.
madrob commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-678451308 > Note the need to set SOLR_JETTY_HOST to bind to all interfaces in the container if you want to expose Solr to your local workstation I previously found the need to set `SOLR_HOST=localhost` with docker containers. Is one way preferred over the other? What's the actual difference? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182093#comment-17182093 ] ASF subversion and git services commented on LUCENE-9433: - Commit 37cd17dcf5730b1aa2055b69c844582beb40faa8 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=37cd17d ] LUCENE-9433: Remove Ant support from trunk > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * -Update any mentions of ant in the ref guide- (on EOE fork) > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task (netbeans too?) > * -various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle- (on EOE fork) > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... > * Make "the best damn beasting script in the world" work with the Gradle > build. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182099#comment-17182099 ] Erick Erickson commented on LUCENE-9433: Pushed, but then realized that I may have to roll it all back to allow the Jenkins jobs to stop using Ant. If I see a bunch of jobs failing I'll roll it back and coordinate better. Leaving this JIRA open for now until that question is answered. > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * -Update any mentions of ant in the ref guide- (on EOE fork) > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task (netbeans too?) > * -various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle- (on EOE fork) > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... > * Make "the best damn beasting script in the world" work with the Gradle > build. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14773) Add LukeRequestHandler to Ref Guide
David Eric Pugh created SOLR-14773: -- Summary: Add LukeRequestHandler to Ref Guide Key: SOLR-14773 URL: https://issues.apache.org/jira/browse/SOLR-14773 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Affects Versions: 8.6.1 Reporter: David Eric Pugh Assignee: David Eric Pugh In learning more about SOLR-13412, I blithe assumed the LukeRequestHandler was in the Ref Guide. It isn't, there is an older cwiki page https://cwiki.apache.org/confluence/display/solr/LukeRequestHandler that is rather hard to understand. Let's add the LukeREquestHandler to the Ref Guide, and then wehn Luke is properly documented, it can be linked from there. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14765) optimize DocList creation by skipping sort for sort-irrelevant cases
[
https://issues.apache.org/jira/browse/SOLR-14765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182105#comment-17182105
]
Mike Drob commented on SOLR-14765:
--
I've seen the combination of cursorMark, MatchAllDocs, and sort by score in the
wild before, and I've told people not to do it. It only leads to pain. They
really want to be using export handler in this type of scenario.
I haven't tried it with searchAfter or skipping sort directly.
> optimize DocList creation by skipping sort for sort-irrelevant cases
>
>
> Key: SOLR-14765
> URL: https://issues.apache.org/jira/browse/SOLR-14765
> Project: Solr
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Michael Gibney
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{rows=0}}, and for {{MatchAllDocsQuery}} and {{ConstantScoreQuery}}
> (and possibly others?), it is possible for
> {{SolrIndexSearcher.getDocListC(QueryResult, QueryCommand)}} to create a
> DocList directly from {{filterCache}} DocSets -- similar to
> {{useFilterForSortedQuery}}, but without actually sorting.
> This results in significant benefits for high-recall domains, including the
> common (and commonly-cached) use-case of {{q=\*:*}} and {{fq}}, facets, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob merged pull request #1759: SOLR-13438: on collection delete, also delete .AUTOCREATED config set
madrob merged pull request #1759: URL: https://github.com/apache/lucene-solr/pull/1759 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13438) DELETE collection should remove AUTOCREATED configsets
[ https://issues.apache.org/jira/browse/SOLR-13438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182106#comment-17182106 ] ASF subversion and git services commented on SOLR-13438: Commit 66b6ce2cd0493f273e95aa51c53a324a4692136e in lucene-solr's branch refs/heads/master from Anderson Dorow [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=66b6ce2 ] SOLR-13438: on collection delete, also delete .AUTOCREATED config set (#1759) Co-authored-by: Anderson Dorow > DELETE collection should remove AUTOCREATED configsets > -- > > Key: SOLR-13438 > URL: https://issues.apache.org/jira/browse/SOLR-13438 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Major > Labels: newdev > Time Spent: 2h > Remaining Estimate: 0h > > Current user experience: > # User creates a collection (without specifying configset), and makes some > schema/config changes. > # He's/She's not happy with how the changes turned out, so he/she deletes and > re-creates the collection. > # He/she observes that the previously made settings changes persist. If > he/she is only aware of Schema and Config APIs and not explicitly aware of > the concept of configsets, this will be un-intuitive for him/her. > Proposed: > DELETE collection should delete the configset if it has the prefix > ".AUTOCREATED" and that configset isn't being shared by any other collection. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss merged pull request #1761: LUCENE-9438: Eclipse IDE support with gradle build system
dweiss merged pull request #1761: URL: https://github.com/apache/lucene-solr/pull/1761 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9438) Add gradle workflow support for Eclipse IDE
[ https://issues.apache.org/jira/browse/LUCENE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-9438. - Fix Version/s: master (9.0) Resolution: Fixed > Add gradle workflow support for Eclipse IDE > --- > > Key: LUCENE-9438 > URL: https://issues.apache.org/jira/browse/LUCENE-9438 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > Attachments: capture-1.png > > Time Spent: 20m > Remaining Estimate: 0h > > Off the top of my head I've tried using the eclipse plugin (this should > prepare "static" classpath entries pointing at local gradle caches). It > almost works... almost because we have references between sub-atomic project > elements (tests and main) that make Eclipse see these as circular (because > Eclipse treats project sources and main classes as one). > I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it > work. I'm not a big fan of having a single "blob" project with all the > sources and classpaths combined (the IDE won't help you figure out what's > accessible from a given subproject then) but maybe it's the only way to make > it work for Eclipse, don't know. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9438) Add gradle workflow support for Eclipse IDE
[ https://issues.apache.org/jira/browse/LUCENE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182109#comment-17182109 ] Dawid Weiss commented on LUCENE-9438: - I've pushed this in, doesn't seem to be clashing with any other effort anyway. > Add gradle workflow support for Eclipse IDE > --- > > Key: LUCENE-9438 > URL: https://issues.apache.org/jira/browse/LUCENE-9438 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: capture-1.png > > Time Spent: 20m > Remaining Estimate: 0h > > Off the top of my head I've tried using the eclipse plugin (this should > prepare "static" classpath entries pointing at local gradle caches). It > almost works... almost because we have references between sub-atomic project > elements (tests and main) that make Eclipse see these as circular (because > Eclipse treats project sources and main classes as one). > I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it > work. I'm not a big fan of having a single "blob" project with all the > sources and classpaths combined (the IDE won't help you figure out what's > accessible from a given subproject then) but maybe it's the only way to make > it work for Eclipse, don't know. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9438) Add gradle workflow support for Eclipse IDE
[ https://issues.apache.org/jira/browse/LUCENE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182108#comment-17182108 ] ASF subversion and git services commented on LUCENE-9438: - Commit b1e2d0c8906615a4de41511fbd1bd663908b7195 in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b1e2d0c ] LUCENE-9438: Eclipse IDE support with gradle build system (#1761) > Add gradle workflow support for Eclipse IDE > --- > > Key: LUCENE-9438 > URL: https://issues.apache.org/jira/browse/LUCENE-9438 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: capture-1.png > > Time Spent: 10m > Remaining Estimate: 0h > > Off the top of my head I've tried using the eclipse plugin (this should > prepare "static" classpath entries pointing at local gradle caches). It > almost works... almost because we have references between sub-atomic project > elements (tests and main) that make Eclipse see these as circular (because > Eclipse treats project sources and main classes as one). > I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it > work. I'm not a big fan of having a single "blob" project with all the > sources and classpaths combined (the IDE won't help you figure out what's > accessible from a given subproject then) but maybe it's the only way to make > it work for Eclipse, don't know. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182111#comment-17182111 ] Dawid Weiss commented on LUCENE-9433: - Oh, you've removed ant. :) I'm fine with it but indeed I'm not sure if there are any additional steps that need to be taken (patch verifier on github, jenkins). Let's wait and see. > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * -Update any mentions of ant in the ref guide- (on EOE fork) > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task (netbeans too?) > * -various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle- (on EOE fork) > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... > * Make "the best damn beasting script in the world" work with the Gradle > build. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182115#comment-17182115
]
Mark Robert Miller commented on SOLR-14636:
---
And a Tim Potter commit hits! How exciting is that, have not seen one of those
in a while. More targeted information dumps coming shortly.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg, jenkins.png, solr-ref-branch.gif
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
> * *core*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: *extremely stable* with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*extremely
> stable*{color} with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
> stable*{color} with {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9474) Change Jenkins jobs to use Gradle for trunk
Erick Erickson created LUCENE-9474: -- Summary: Change Jenkins jobs to use Gradle for trunk Key: LUCENE-9474 URL: https://issues.apache.org/jira/browse/LUCENE-9474 Project: Lucene - Core Issue Type: Test Components: general/build Reporter: Erick Erickson Assignee: Uwe Schindler I rushed the gate and pushed LUCENE-9433 without coordinating, my apologies for the confusion. Meanwhile, Uwe has disabled Jenkins jobs for the weekend and we'll fix this up Real Soon Now. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13438) DELETE collection should remove AUTOCREATED configsets
[ https://issues.apache.org/jira/browse/SOLR-13438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182127#comment-17182127 ] ASF subversion and git services commented on SOLR-13438: Commit fc5e07ac38520162aa5af394f95978b0478cda8b in lucene-solr's branch refs/heads/branch_8x from Anderson Dorow [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fc5e07a ] SOLR-13438: on collection delete, also delete .AUTOCREATED config set (#1759) Co-authored-by: Anderson Dorow > DELETE collection should remove AUTOCREATED configsets > -- > > Key: SOLR-13438 > URL: https://issues.apache.org/jira/browse/SOLR-13438 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Major > Labels: newdev > Time Spent: 2h > Remaining Estimate: 0h > > Current user experience: > # User creates a collection (without specifying configset), and makes some > schema/config changes. > # He's/She's not happy with how the changes turned out, so he/she deletes and > re-creates the collection. > # He/she observes that the previously made settings changes persist. If > he/she is only aware of Schema and Config APIs and not explicitly aware of > the concept of configsets, this will be un-intuitive for him/her. > Proposed: > DELETE collection should delete the configset if it has the prefix > ".AUTOCREATED" and that configset isn't being shared by any other collection. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13438) DELETE collection should remove AUTOCREATED configsets
[ https://issues.apache.org/jira/browse/SOLR-13438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob reassigned SOLR-13438: Assignee: Mike Drob > DELETE collection should remove AUTOCREATED configsets > -- > > Key: SOLR-13438 > URL: https://issues.apache.org/jira/browse/SOLR-13438 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Assignee: Mike Drob >Priority: Major > Labels: newdev > Time Spent: 2h > Remaining Estimate: 0h > > Current user experience: > # User creates a collection (without specifying configset), and makes some > schema/config changes. > # He's/She's not happy with how the changes turned out, so he/she deletes and > re-creates the collection. > # He/she observes that the previously made settings changes persist. If > he/she is only aware of Schema and Config APIs and not explicitly aware of > the concept of configsets, this will be un-intuitive for him/her. > Proposed: > DELETE collection should delete the configset if it has the prefix > ".AUTOCREATED" and that configset isn't being shared by any other collection. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13438) DELETE collection should remove AUTOCREATED configsets
[ https://issues.apache.org/jira/browse/SOLR-13438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob resolved SOLR-13438. -- Fix Version/s: 8.7 master (9.0) Resolution: Fixed Thanks for the patch Anderson! Pushed to 9.0 and 8.7 > DELETE collection should remove AUTOCREATED configsets > -- > > Key: SOLR-13438 > URL: https://issues.apache.org/jira/browse/SOLR-13438 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Assignee: Mike Drob >Priority: Major > Labels: newdev > Fix For: master (9.0), 8.7 > > Time Spent: 2h > Remaining Estimate: 0h > > Current user experience: > # User creates a collection (without specifying configset), and makes some > schema/config changes. > # He's/She's not happy with how the changes turned out, so he/she deletes and > re-creates the collection. > # He/she observes that the previously made settings changes persist. If > he/she is only aware of Schema and Config APIs and not explicitly aware of > the concept of configsets, this will be un-intuitive for him/her. > Proposed: > DELETE collection should delete the configset if it has the prefix > ".AUTOCREATED" and that configset isn't being shared by any other collection. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9474) Change Jenkins jobs to use Gradle for trunk
[ https://issues.apache.org/jira/browse/LUCENE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182144#comment-17182144 ] Cassandra Targett commented on LUCENE-9474: --- The Ref Guide master build I just spent 2 weeks fixing have not been disabled, as I'm getting spammed while on vacation. Please disable these, and please add them to the list of jobs that need to get fixed so I don't end up having to do it by myself. > Change Jenkins jobs to use Gradle for trunk > --- > > Key: LUCENE-9474 > URL: https://issues.apache.org/jira/browse/LUCENE-9474 > Project: Lucene - Core > Issue Type: Test > Components: general/build >Reporter: Erick Erickson >Assignee: Uwe Schindler >Priority: Major > > I rushed the gate and pushed LUCENE-9433 without coordinating, my apologies > for the confusion. > Meanwhile, Uwe has disabled Jenkins jobs for the weekend and we'll fix this > up Real Soon Now. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182145#comment-17182145 ] ASF subversion and git services commented on LUCENE-9433: - Commit c9c75810c229c2a1d54a05a6d79abd3c66f0b437 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c9c7581 ] Revert "LUCENE-9433: Remove Ant support from trunk" This reverts commit 37cd17dc > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * -Update any mentions of ant in the ref guide- (on EOE fork) > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task (netbeans too?) > * -various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle- (on EOE fork) > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... > * Make "the best damn beasting script in the world" work with the Gradle > build. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9474) Change Jenkins jobs to use Gradle for trunk
[ https://issues.apache.org/jira/browse/LUCENE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182144#comment-17182144 ] Cassandra Targett edited comment on LUCENE-9474 at 8/21/20, 8:58 PM: - -The Ref Guide master build I just spent 2 weeks fixing have not been disabled-, as I'm getting spammed while on vacation. Please disable these, and please add them to the list of jobs that need to get fixed so I don't end up having to do it by myself. Edit: my mistake. I interrupted my vacation to investigate and didn't see all the chatter in Slack about this until after this comment. was (Author: ctargett): The Ref Guide master build I just spent 2 weeks fixing have not been disabled, as I'm getting spammed while on vacation. Please disable these, and please add them to the list of jobs that need to get fixed so I don't end up having to do it by myself. > Change Jenkins jobs to use Gradle for trunk > --- > > Key: LUCENE-9474 > URL: https://issues.apache.org/jira/browse/LUCENE-9474 > Project: Lucene - Core > Issue Type: Test > Components: general/build >Reporter: Erick Erickson >Assignee: Uwe Schindler >Priority: Major > > I rushed the gate and pushed LUCENE-9433 without coordinating, my apologies > for the confusion. > Meanwhile, Uwe has disabled Jenkins jobs for the weekend and we'll fix this > up Real Soon Now. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] epugh opened a new pull request #1773: SOLR-14773 Add LukeRequestHandler to the Solr Ref Guide
epugh opened a new pull request #1773: URL: https://github.com/apache/lucene-solr/pull/1773 To replace the old https://cwiki.apache.org/confluence/display/solr/LukeRequestHandler page, and eventually provide a link to the Luke application's getting started page! 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
Tomas Eduardo Fernandez Lobbe created SOLR-14774:
Summary: HealthCheckHandler shouldn't be an implicit SolrCore
level handler and should be configurable
Key: SOLR-14774
URL: https://issues.apache.org/jira/browse/SOLR-14774
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomas Eduardo Fernandez Lobbe
While trying to use the HealthCheckHandler I noticed that:
* CoreContainer has some logic to read config from {{solr.xml}}, however, this
is never used, and the handler is constructed explicitly inside
{{InfoHandler}}. This means you can't plugin a different implementation.
* Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
which means one could access the handler like
{{//admin/health}}, however, this will never work, since it
uses a parameterless constructor, which leaves the handler in an invalid state
[1]. I honestly don't know why it's being added to the {{SolrCore}}, this is
supposed to be a node level handler, and for SolrCore one could use the
{{PingRequestHandler}}
[1]
{noformat}
2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
null:org.apache.solr.common.SolrException: CoreContainer is either not
initialized or shutting down
at
org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
at
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:500)
at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(Ea
[jira] [Commented] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182159#comment-17182159
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14774:
--
[~shalin], [~sarkaramr...@gmail.com], there was some discussion about this in
SOLR-11126, let me know if you see something I'm missing
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Major
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.H
[GitHub] [lucene-solr] thelabdude commented on pull request #1769: SOLR-11245: Absorb the docker-solr repo.
thelabdude commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-678536391 > > Note the need to set SOLR_JETTY_HOST to bind to all interfaces in the container if you want to expose Solr to your local workstation > > I previously found the need to set `SOLR_HOST=localhost` with docker containers. Is one way preferred over the other? What's the actual difference? @madrob This commit here (https://github.com/apache/lucene-solr/commit/5377742a62e58c79055f3a2676b77e1ed1d61823#diff-2e431666cd6c6f1e08f79cdefa4988a4) makes it so Jetty only binds to 127.0.0.1 in the Docker container, which messes up Docker's ability to expose port 8983 outside of the container. It looks like that was done for security reasons ... So setting SOLR_JETTY_HOST to 0.0.0.0 allows me to reach Solr from outside Docker using http://locahost:8983 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14684) CloudExitableDirectoryReaderTest failing about 25% of the time
[
https://issues.apache.org/jira/browse/SOLR-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182182#comment-17182182
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14684:
--
There are a bunch of failures in Jenkins like:
{noformat}
FAILED:
org.apache.solr.client.solrj.impl.LBSolrClientTest.testServerIteratorTimeAllowed
Error Message:
Expected exception SolrServerException but no exception was thrown
Stack Trace:
junit.framework.AssertionFailedError: Expected exception SolrServerException
but no exception was thrown
at
org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2750)
at
org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2740)
at
org.apache.solr.client.solrj.impl.LBSolrClientTest.testServerIteratorTimeAllowed(LBSolrClientTest.java:77)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:269)
at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:394)
at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)
{noformat}
Looks related to this commit, but I didn't validate
> CloudExitableDirectoryReaderTest failing about 25% of the time
> --
>
> Key: SOLR-14684
> URL: https://issues.apache.org/jira/browse/SOLR-14684
> Project: Solr
> Issue Type: Test
> Components: Tests
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Priority: Major
> Attachments: stdout
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If I beast this on my local machine, it fails (non reproducibly of course)
> about 1/4 of the time. Log attached. The test itself hasn't changed in 11
> months or so.
> It looks like occasionally the calls throw an error rather than return
> partial results with a message: "Time allowed to handle this request
> exceeded:[]".
> It's been failing very intermittently for a couple of years, but the failure
> rate really picked up in the last couple of weeks. IDK whether the failures
> prior to the last couple of weeks are the same root cause.
> I'll do some spelunking to see if I can pinpoint the commit that made this
> happen, but it'll take a while.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14684) CloudExitableDirectoryReaderTest failing about 25% of the time
[ https://issues.apache.org/jira/browse/SOLR-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182186#comment-17182186 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-14684: -- Ah, I noticed Erick created SOLR-14771 for the failure > CloudExitableDirectoryReaderTest failing about 25% of the time > -- > > Key: SOLR-14684 > URL: https://issues.apache.org/jira/browse/SOLR-14684 > Project: Solr > Issue Type: Test > Components: Tests >Affects Versions: master (9.0) >Reporter: Erick Erickson >Priority: Major > Attachments: stdout > > Time Spent: 40m > Remaining Estimate: 0h > > If I beast this on my local machine, it fails (non reproducibly of course) > about 1/4 of the time. Log attached. The test itself hasn't changed in 11 > months or so. > It looks like occasionally the calls throw an error rather than return > partial results with a message: "Time allowed to handle this request > exceeded:[]". > It's been failing very intermittently for a couple of years, but the failure > rate really picked up in the last couple of weeks. IDK whether the failures > prior to the last couple of weeks are the same root cause. > I'll do some spelunking to see if I can pinpoint the commit that made this > happen, but it'll take a while. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Robert Miller updated SOLR-14636:
--
Description:
SolrCloud powers critical infrastructure and needs the ability to run quickly
with stability. This reference implementation will allow for this.
*location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
*status*: developer alpha, on the verge of developer beta
*speed*: ludicrous
*tests***:
* *core*: {color:#00875a}*extremely stable*{color} with
*{color:#de350b}ignores{color}*
* *solrj*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
* *contrib/analysis-extras*: *extremely stable* with
{color:#de350b}*ignores*{color}
* *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
*{color:#de350b}ignores{color}*
* *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/dataimporthandler-extras*: {color:#00875a}*extremely stable*{color}
with *{color:#de350b}ignores{color}*
* *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
stable*{color} with {color:#de350b}*ignores*{color}
* *contrib/langid*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
_* Running tests quickly and efficiently with strict policing will more
frequently find bugs and requires a period of hardening._
_** Non Nightly currently, Nightly comes last._
h2. Getting Started with the Solr Reference Branch
# Book One: [The 10 Minute Introduction
|https://www.dropbox.com/sh/prnw0gpdoi0j9me/AABF2gPDoer6uL0ghXfEzbzja?dl=0]
# Book Two: A Brief, High Level Overview of the Changes <{color:#de350b}*_WORK
IN PROGRESS_*{color}>
was:
SolrCloud powers critical infrastructure and needs the ability to run quickly
with stability. This reference implementation will allow for this.
*location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
*status*: alpha
*speed*: ludicrous
*tests***:
* *core*: {color:#00875a}*extremely stable*{color} with
*{color:#de350b}ignores{color}*
* *solrj*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
* *contrib/analysis-extras*: *extremely stable* with
{color:#de350b}*ignores*{color}
* *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
*{color:#de350b}ignores{color}*
* *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/dataimporthandler-extras*: {color:#00875a}*extremely stable*{color}
with *{color:#de350b}ignores{color}*
* *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
stable*{color} with {color:#de350b}*ignores*{color}
* *contrib/langid*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
_* Running tests quickly and efficiently with strict policing will more
frequently find bugs and requires a period of hardening._
_** Non Nightly currently, Nightly comes last._
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg, jenkins.png, solr-ref-branch.gif
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: developer alpha, on the verge of developer beta
> *speed*: ludicrous
> *tests***:
> * *core*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{col
[jira] [Commented] (SOLR-14383) Fix indexing-nested-documents.adoc XML/JSON examples to be accurate, consistent, and clear
[
https://issues.apache.org/jira/browse/SOLR-14383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182195#comment-17182195
]
Chris M. Hostetter commented on SOLR-14383:
---
FWIW: i keep going back and forth on _where_ it makes the most sense to explain
non-trivial of/which params.
My current thinking, as reflected in my latest branch commits, is that
{{other-parsers.adoc}} should have a sub section introducing the _concept_
(which i've labeled "Block Mask" to differentiate from "all parents" when it
has to include docs which are not parents or children) that explains how/why it
can be tricky in non-trivial situations, and then the (later and more in depth)
{{searching-nested-documents.adoc}} go into the specifics of writing good
"Block Mask" queries when using {{_nest_path_}} with multi-level hierarchies.
(still work to be done, but i'm about to go offline for a week and didn't want
to forget this on my laptop)
> Fix indexing-nested-documents.adoc XML/JSON examples to be accurate,
> consistent, and clear
> --
>
> Key: SOLR-14383
> URL: https://issues.apache.org/jira/browse/SOLR-14383
> Project: Solr
> Issue Type: Sub-task
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14383.patch, SOLR-14383.patch, SOLR-14383.patch,
> SOLR-14383.patch
>
>
> As reported on solr-user@lucene by Peter Pimley...
> {noformat}
> The page "Indexing Nested Documents" has an XML example showing two
> different ways of adding nested documents:
> https://lucene.apache.org/solr/guide/8_5/indexing-nested-documents.html#xml-examples
> The text says:
> "It illustrates two styles of adding child documents: the first is
> associated via a field "comment" (preferred), and the second is done
> in the classic way now referred to as an "anonymous" or "unlabelled"
> child document."
> However in the XML directly below there is no field named "comment".
> There is one named "content" and another named "comments" (plural),
> but no field named "comment". In fact, looking at the Json example
> immediately below, I wonder if the XML element currently named
> "content" should be named "comments", and what is currently marked
> "comments" should be "content"?
> Secondly, in the Json example it says:
> "The labelled relationship here is one child document but could have
> been wrapped in array brackets."
> However in the actual Json, the parent document (ID=1) with a labelled
> relationship has two child documents (IDs 2 and 3), and they are
> already in array brackets.
> {noformat}
> * The 2 examples (XML and JSON) should be updated to contains *structurally*
> identical content, (ie: same number of documents, with same field values, and
> same hierarchical relationships) to focus on demonstrating the syntax
> differences (ie: things like the special {{\_childDocuments\_}} key in json)
> * The paragraphs describing the examples should be updated to:
> ** refer to the correct field names -- since both "comments" and "contents"
> fields exist in the examples, it's impossible for novice users to even
> udnerstand where th "typo" might be in the descriptions (I'm pretty
> knowledgeable about Solr and even i'm second guessing myself as to what the
> intent in these paragraphs are)
> ** refer to documents by {{"id"}} value, not just descriptors like "first"
> and "second"
> * it might be worth considering rewriting this section to use "callouts":
> https://asciidoctor.org/docs/user-manual/#callouts -- similar to how we use
> them in other sections like this:
> https://lucene.apache.org/solr/guide/8_5/uploading-data-with-index-handlers.html#sending-json-update-commands
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182220#comment-17182220
]
Ishan Chattopadhyaya commented on SOLR-14636:
-
Welcome and thanks [~thelabdude]! Haven't said this enough, but I sincerely
thank you [~markrmiller] for your tireless effort in turning around Solr from
where it is (I'll not use pejoratives in a public forum). Your work is one of
the only rays of hope Solr has seen in a decade in this space, and Solr users
(esp faceless DevOps engineers across the world) will thank you for saving the
project. I offer my full support in making this branch as stable and reliable
as possible.
bq. More targeted information dumps coming shortly.
Eagerly looking forward to it.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg, jenkins.png, solr-ref-branch.gif
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: developer alpha, on the verge of developer beta
> *speed*: ludicrous
> *tests***:
> * *core*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: *extremely stable* with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*extremely
> stable*{color} with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
> stable*{color} with {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
> h2. Getting Started with the Solr Reference Branch
> # Book One: [The 10 Minute Introduction
> |https://www.dropbox.com/sh/prnw0gpdoi0j9me/AABF2gPDoer6uL0ghXfEzbzja?dl=0]
> # Book Two: A Brief, High Level Overview of the Changes
> <{color:#de350b}*_WORK IN PROGRESS_*{color}>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14750) Harden TestBulkSchemaConcurrent
[ https://issues.apache.org/jira/browse/SOLR-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-14750. --- Fix Version/s: 8.7 Resolution: Fixed > Harden TestBulkSchemaConcurrent > --- > > Key: SOLR-14750 > URL: https://issues.apache.org/jira/browse/SOLR-14750 > Project: Solr > Issue Type: Improvement > Components: Tests >Reporter: Erick Erickson >Assignee: Noble Paul >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-14750.patch > > Time Spent: 1h > Remaining Estimate: 0h > > This test has been failing quite often lately. I poked around a bit and see > what I _think_ is evidence of a race condition in CoreContainer.reload where > a reload on the same core is happening from two places in close succession. > I'll attach a preliminary patch soon. > Without this patch I had 25 failures out of 1,000 runs, with it 0. > I consider this patch a WIP, putting up for comment. Well, it has nocommits > so... But In particular, I have to review some changes I made about which > name we're using for PendingCoreOps. I also want to back out my changes and > beast it again with some more logging to see if I can nail down that multiple > reloads are happening before declaring victory. > What this does is put the name of the core we're reloading in pendingCoreOps > earlier in the reload process. Then the second call to reload will wait until > the first is completed. I also restructured it a bit because I don't like if > clauses that go on forever and a small else clause way down the code. I > inverted the test and bailed out of the method rather than fall off the end > after the else clause. > One thing I don't like about this is two reloads in such rapid succession > seems wasteful. Even so, I can imagine that one reload gets through far > enough to load the schema, then a schema update changes the schema _then_ > calls reload. So I don't think just returning if there's a reload happening > on that core already is valid. > More to come. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182227#comment-17182227
]
Mark Robert Miller commented on SOLR-14636:
---
Thanks Ishan - honestly, without the faith and interest from you and Noble and
David last year, I’d have certainly given up here and moved my process to new
or other Java code. Oh no, there goes the annoying 10x dev :) Or it is 1000.
No, but the process and discovery I stumbled upon is 10x. And open to anyone.
Let’s build something we can be proud of.
I will be providing a series of drops to get interested parties up to speed in
the description of this issue - the first overview drop is there, I’ll start
diving into things going forward. There is plenty to discuss and consider and
evaluate. I am attached to nothing but stability, scale and speed. The
solutions to make it happen is not my special purview. Once people start to
understand the differences here on a more experiential level, we will be ready
to really move.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg, jenkins.png, solr-ref-branch.gif
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: developer alpha, on the verge of developer beta
> *speed*: ludicrous
> *tests***:
> * *core*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: *extremely stable* with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*extremely
> stable*{color} with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
> stable*{color} with {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
> h2. Getting Started with the Solr Reference Branch
> # Book One: [The 10 Minute Introduction
> |https://www.dropbox.com/sh/prnw0gpdoi0j9me/AABF2gPDoer6uL0ghXfEzbzja?dl=0]
> # Book Two: A Brief, High Level Overview of the Changes
> <{color:#de350b}*_WORK IN PROGRESS_*{color}>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe opened a new pull request #1774: SOLR-14774: Create HealthCheckHandler in CoreContainer
tflobbe opened a new pull request #1774: URL: https://github.com/apache/lucene-solr/pull/1774 This allows users to plug-in different implementations of the handler (they must extend HealthCheckHandler) This PR also removes the HealthCheckHandler from the implicit SolrCore plugins 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Robert Miller updated SOLR-14636:
--
Description:
SolrCloud powers critical infrastructure and needs the ability to run quickly
with stability. This reference implementation will allow for this.
*location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
*status*: developer alpha, on the verge of developer beta
*speed*: ludicrous
*tests***:
* *core*: {color:#00875a}*extremely stable*{color} with
*{color:#de350b}ignores{color}*
* *solrj*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
* *contrib/analysis-extras*: *extremely stable* with
{color:#de350b}*ignores*{color}
* *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
*{color:#de350b}ignores{color}*
* *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/dataimporthandler-extras*: {color:#00875a}*extremely stable*{color}
with *{color:#de350b}ignores{color}*
* *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
stable*{color} with {color:#de350b}*ignores*{color}
* *contrib/langid*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
_* Running tests quickly and efficiently with strict policing will more
frequently find bugs and requires a period of hardening._
_** Non Nightly currently, Nightly comes last._
h2. Getting Started with the Solr Reference Branch
[AYoungLadysIllustratedPrimer|https://www.dropbox.com/sh/prnw0gpdoi0j9me/AABF2gPDoer6uL0ghXfEzbzja?dl=0]
# Book One: [The 10 Minute Introduction
|https://www.dropbox.com/s/x9k1m3zmjucc422/Book%20One%3A%20The%2010%20Minute%20Introduction.mp4?dl=0]
# Book Two: A Brief, High Level Overview of the Changes <{color:#de350b}*_WORK
IN PROGRESS_*{color}>
# Book Three: Diving In: Section1: [LifeCycle, LifeCycle,
LifeCycle|https://www.dropbox.com/s/zno3qftzekyo3ac/Book%20Three%3A%20Diving%20In%3A%20Section%201%3A%20LifeCycle%2C%2CLifeCycle%2CLifeCycle.m4v?dl=0]
was:
SolrCloud powers critical infrastructure and needs the ability to run quickly
with stability. This reference implementation will allow for this.
*location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
*status*: developer alpha, on the verge of developer beta
*speed*: ludicrous
*tests***:
* *core*: {color:#00875a}*extremely stable*{color} with
*{color:#de350b}ignores{color}*
* *solrj*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
* *contrib/analysis-extras*: *extremely stable* with
{color:#de350b}*ignores*{color}
* *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
*{color:#de350b}ignores{color}*
* *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/dataimporthandler-extras*: {color:#00875a}*extremely stable*{color}
with *{color:#de350b}ignores{color}*
* *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
stable*{color} with {color:#de350b}*ignores*{color}
* *contrib/langid*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
* *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
{color:#de350b}*ignores*{color}
_* Running tests quickly and efficiently with strict policing will more
frequently find bugs and requires a period of hardening._
_** Non Nightly currently, Nightly comes last._
h2. Getting Started with the Solr Reference Branch
# Book One: [The 10 Minute Introduction
|https://www.dropbox.com/sh/prnw0gpdoi0j9me/AABF2gPDoer6uL0ghXfEzbzja?dl=0]
# Book Two: A Brief, High Level Overview of the Changes <{color:#de350b}*_WORK
IN PROGRESS_*{color}>
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-146
[jira] [Commented] (LUCENE-9474) Change Jenkins jobs to use Gradle for trunk
[ https://issues.apache.org/jira/browse/LUCENE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182243#comment-17182243 ] Tomoko Uchida commented on LUCENE-9474: --- +1. It's a great step to real transition to Gradle build, thank you! > Change Jenkins jobs to use Gradle for trunk > --- > > Key: LUCENE-9474 > URL: https://issues.apache.org/jira/browse/LUCENE-9474 > Project: Lucene - Core > Issue Type: Test > Components: general/build >Reporter: Erick Erickson >Assignee: Uwe Schindler >Priority: Major > > I rushed the gate and pushed LUCENE-9433 without coordinating, my apologies > for the confusion. > Meanwhile, Uwe has disabled Jenkins jobs for the weekend and we'll fix this > up Real Soon Now. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
