[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1770: SOLR-14763 SolrJ HTTP/2 Async API using CompletableFuture
dsmiley commented on a change in pull request #1770:
URL: https://github.com/apache/lucene-solr/pull/1770#discussion_r475342747
##
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:
What you propose sounds good Rishi.
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-9373) Allow FunctionMatchQuery to customize matchCost of TwoPhaseIterator
[ https://issues.apache.org/jira/browse/LUCENE-9373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved LUCENE-9373. -- Fix Version/s: 8.7 Resolution: Fixed > Allow FunctionMatchQuery to customize matchCost of TwoPhaseIterator > --- > > Key: LUCENE-9373 > URL: https://issues.apache.org/jira/browse/LUCENE-9373 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/queries >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Labels: newdev > Fix For: 8.7 > > Attachments: LUCENE-9373.patch, LUCENE-9373.patch > > > FunctionMatchQuery internally has a TwoPhaseIterator using a constant > matchCost. If it were customizable by the query, the user could control this > ordering. I propose an optional matchCost via an overloaded constructor. > Ideally the DoubleValues abstraction would have a matchCost but it doesn't, > and even if it did, the user might just want real control over this at a > query construction/parse level. > See similar LUCENE-9114 -- 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-9373) Allow FunctionMatchQuery to customize matchCost of TwoPhaseIterator
[ https://issues.apache.org/jira/browse/LUCENE-9373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182948#comment-17182948 ] ASF subversion and git services commented on LUCENE-9373: - Commit 654ee3bee4f567d5e3043b2f2ae0873714ea5fd3 in lucene-solr's branch refs/heads/branch_8x from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=654ee3b ] LUCENE-9373: FunctionMatchQuery: add "matchCost" param (cherry picked from commit e1392c74400d74366982ccb796063ffdcef08047) > Allow FunctionMatchQuery to customize matchCost of TwoPhaseIterator > --- > > Key: LUCENE-9373 > URL: https://issues.apache.org/jira/browse/LUCENE-9373 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/queries >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Labels: newdev > Attachments: LUCENE-9373.patch, LUCENE-9373.patch > > > FunctionMatchQuery internally has a TwoPhaseIterator using a constant > matchCost. If it were customizable by the query, the user could control this > ordering. I propose an optional matchCost via an overloaded constructor. > Ideally the DoubleValues abstraction would have a matchCost but it doesn't, > and even if it did, the user might just want real control over this at a > query construction/parse level. > See similar LUCENE-9114 -- 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-9373) Allow FunctionMatchQuery to customize matchCost of TwoPhaseIterator
[ https://issues.apache.org/jira/browse/LUCENE-9373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182946#comment-17182946 ] ASF subversion and git services commented on LUCENE-9373: - Commit e1392c74400d74366982ccb796063ffdcef08047 in lucene-solr's branch refs/heads/master from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e1392c7 ] LUCENE-9373: FunctionMatchQuery: add "matchCost" param > Allow FunctionMatchQuery to customize matchCost of TwoPhaseIterator > --- > > Key: LUCENE-9373 > URL: https://issues.apache.org/jira/browse/LUCENE-9373 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/queries >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Labels: newdev > Attachments: LUCENE-9373.patch, LUCENE-9373.patch > > > FunctionMatchQuery internally has a TwoPhaseIterator using a constant > matchCost. If it were customizable by the query, the user could control this > ordering. I propose an optional matchCost via an overloaded constructor. > Ideally the DoubleValues abstraction would have a matchCost but it doesn't, > and even if it did, the user might just want real control over this at a > query construction/parse level. > See similar LUCENE-9114 -- 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-14651) Metrics history could disable itself better
[ https://issues.apache.org/jira/browse/SOLR-14651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182937#comment-17182937 ] David Smiley commented on SOLR-14651: - No; I think the documentation here is fine? https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/metrics-history.adoc (search for "enable") > Metrics history could disable itself better > --- > > Key: SOLR-14651 > URL: https://issues.apache.org/jira/browse/SOLR-14651 > Project: Solr > Issue Type: Improvement > Components: metrics >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 8.7 > > Time Spent: 50m > Remaining Estimate: 0h > > The MetricsHistoryHandler should disable itself better than it does. It will > create a SolrRrdBackendFactory (which has an ExecutorService / thread pool) > when it should not when the plugin is disabled. Furthermore, I think this > should be disabled by default in tests, as it's excessive machinery that > don't matter to 99.9% of tests. This will help our tests run more > efficiently. > While working on other issues, I also occasionally saw a thread leak failure > with the RRD being the leaked threads. I see that in "close", we don't > _wait_ for the executor to actually shut down but it should. > CC [~ab] -- 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-14775) Disable metrics collection
[ https://issues.apache.org/jira/browse/SOLR-14775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182927#comment-17182927 ] David Smiley commented on SOLR-14775: - The wording "disable metrics collection" suggests this is about _collection_ of metrics. To my knowledge, only the Metrics History Handler does this within Solr. Is that what this is about? I already worked on an issue for it to disable itself better. I know Mark did this as well in his branch (what you point to). I think it should be disabled by default. That should be it's own issue clearly saying that. IMO The handler ought to also be a plugin; it adds a dependency (RRD4j); also its own issue. I suspect here maybe you mean something broader than that component or else you would have referred to it by name. > Disable metrics collection > -- > > Key: SOLR-14775 > URL: https://issues.apache.org/jira/browse/SOLR-14775 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > There is no clean way to disable metrics collection. There are potential > performance issues (as discovered in SOLR-14636) with metrics collection. Let > us build easy switches to disable this. -- 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-14771) Reproducible failure for LBSolrClientTest
[ https://issues.apache.org/jira/browse/SOLR-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-14771. - Resolution: Fixed Solved by latest commit of SOLR-14684 > 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
[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=17182917#comment-17182917 ] ASF subversion and git services commented on SOLR-14684: Commit a4a0d9e8ce6b48da00ca54cb1fcc0210735aca9b in lucene-solr's branch refs/heads/master from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a4a0d9e ] SOLR-14684: Skipping check time exceeded for the first request in a proper way > 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
[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 Two: Process Intro: Section 1: [A Quick Look at the Practical
Process|https://www.dropbox.com/s/96owizh57i5vd8w/Book%20Two%3A%20Process%20Intro%3A%20Section%201%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
## Book Two: Process Intro: Section 2: [A Brief Look at a Few Broad
Problems|https://www.dropbox.com/s/kmkp1lu1tfits1p/Book%20Two%3A%20Process%20Intro%3A%20Section%202%3A%20A%20Brief%20Look%20at%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 3: [Die, Die, Die Solr
XML|https://www.dropbox.com/s/hi452cpjjx1h880/Book%20Two%3A%20Process%20Intro%3A%20Section%203%3A%20Die%2C%20Die%2C%20Die%20Solr%20XML.m4v?dl=0]
## Book Two: Process Intro: Section 4: [Back to a Few Broad
Problems|https://www.dropbox.com/s/tmeayi23p0rmgda/Book%20Two%3A%20Process%20Intro%3A%20Section%204%3A%20Back%20to%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 4-2: [Back to a Few Broad
Problem|https://www.dropbox.com/s/1olr1v99t73uoml/Book%20Two%3A%20Process%20Intro%3A%20Section%204-2%3A%20Back%20to%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 6: [Step 5, Own the
World|https://www.dropbox.com/s/usdki6wb1qy6fy9/Book%20Two%3A%20Process%20Intro%3A%20Section%206%3A%20Step%205%2C%20Own%20World.m4v?dl=0]
# 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]
# Book Four: Going Forward: Section 1: [A more positive
message|https://www.dropbox.com/s/d1dj9ean8jqb4j6/Book%20Four%3A%20Going%20Forward%3A%20Section%201%3A%20A%20more%20positive%20message.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
[GitHub] [lucene-solr] gautamworah96 commented on a change in pull request #1733: LUCENE-9450 Use BinaryDocValues in the taxonomy writer
gautamworah96 commented on a change in pull request #1733:
URL: https://github.com/apache/lucene-solr/pull/1733#discussion_r475300614
##
File path:
lucene/facet/src/java/org/apache/lucene/facet/taxonomy/directory/DirectoryTaxonomyReader.java
##
@@ -322,9 +324,14 @@ public FacetLabel getPath(int ordinal) throws IOException {
return res;
}
}
-
-Document doc = indexReader.document(ordinal);
-FacetLabel ret = new
FacetLabel(FacetsConfig.stringToPath(doc.get(Consts.FULL)));
+
+int readerIndex = ReaderUtil.subIndex(ordinal, indexReader.leaves());
+LeafReader leafReader = indexReader.leaves().get(readerIndex).reader();
+BinaryDocValues values = leafReader.getBinaryDocValues(Consts.FULL);
Review comment:
I created a new issue [LUCENE
9476](https://issues.apache.org/jira/browse/LUCENE-9476#)
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] (LUCENE-9476) Add a bulk ordinal->FacetLabel API
[
https://issues.apache.org/jira/browse/LUCENE-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gautam Worah updated LUCENE-9476:
-
Description:
This issue is a spillover from the
[PR|https://github.com/apache/lucene-solr/pull/1733/files] for LUCENE 9450
The idea here is to share a single {{BinaryDocValues}} instance per leaf per
query instead of creating a new one each time in the
{{DirectoryTaxonomyReader}}.
Suggested by [~mikemccand]
was:
This issue is a spillover from the
[PR|https://github.com/apache/lucene-solr/pull/1733/files] for LUCENE 9450
The idea here is to share a single {{BinaryDocValues}} instance per leaf per
query instead of creating a new one each time in the DirectoryTaxonomyReader.
Suggested by [~mikemccand]
> Add a bulk ordinal->FacetLabel API
> --
>
> Key: LUCENE-9476
> URL: https://issues.apache.org/jira/browse/LUCENE-9476
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
>Affects Versions: 8.6.1
>Reporter: Gautam Worah
>Priority: Minor
> Labels: performance
>
> This issue is a spillover from the
> [PR|https://github.com/apache/lucene-solr/pull/1733/files] for LUCENE 9450
> The idea here is to share a single {{BinaryDocValues}} instance per leaf per
> query instead of creating a new one each time in the
> {{DirectoryTaxonomyReader}}.
> Suggested by [~mikemccand]
>
>
>
--
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-9476) Add a bulk ordinal->FacetLabel API
[
https://issues.apache.org/jira/browse/LUCENE-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gautam Worah updated LUCENE-9476:
-
Description:
This issue is a spillover from the
[PR|https://github.com/apache/lucene-solr/pull/1733/files] for LUCENE 9450
The idea here is to share a single {{BinaryDocValues}} instance per leaf per
query instead of creating a new one each time in the DirectoryTaxonomyReader.
Suggested by [~mikemccand]
was:
This issue is a spillover from the
[PR|https://github.com/apache/lucene-solr/pull/1733/files] for LUCENE 9450
The idea here is to share a single {{BinaryDocValues}} instance per leaf per
query instead of creating a new one each time.
Suggested by [~mikemccand]
> Add a bulk ordinal->FacetLabel API
> --
>
> Key: LUCENE-9476
> URL: https://issues.apache.org/jira/browse/LUCENE-9476
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
>Affects Versions: 8.6.1
>Reporter: Gautam Worah
>Priority: Minor
> Labels: performance
>
> This issue is a spillover from the
> [PR|https://github.com/apache/lucene-solr/pull/1733/files] for LUCENE 9450
> The idea here is to share a single {{BinaryDocValues}} instance per leaf per
> query instead of creating a new one each time in the DirectoryTaxonomyReader.
> Suggested by [~mikemccand]
>
>
>
--
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-9476) Add a bulk ordinal->FacetLabel API
Gautam Worah created LUCENE-9476:
Summary: Add a bulk ordinal->FacetLabel API
Key: LUCENE-9476
URL: https://issues.apache.org/jira/browse/LUCENE-9476
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Affects Versions: 8.6.1
Reporter: Gautam Worah
This issue is a spillover from the
[PR|https://github.com/apache/lucene-solr/pull/1733/files] for LUCENE 9450
The idea here is to share a single {{BinaryDocValues}} instance per leaf per
query instead of creating a new one each time.
Suggested by [~mikemccand]
--
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=17182869#comment-17182869 ] ASF subversion and git services commented on LUCENE-9474: - Commit 42d07d878e474b692330ac86da09b0962d7798d6 in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=42d07d8 ] LUCENE-9474: Add back tests.haltonfailure for jenkins compatibility (use boolean as default) - type fix > 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-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=17182867#comment-17182867
]
Uwe Schindler commented on LUCENE-9474:
---
I figured it out and added to test config: {{ignoreFailures =
(propertyOrDefault("tests.haltonfailure", "true").toBoolean() == false)}}
This is solely used by jenkins, to run the whole build but completely ignore
test failures. This enabled the useful jenkins feature:
- If only tests fail, build is marked as "unstable"
- If compilation or something else fails, it's serius and the build is marked
as "failed"
> 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-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=17182866#comment-17182866 ] ASF subversion and git services commented on LUCENE-9474: - Commit 863d54437840369777815ce9d0749078ef806265 in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=863d544 ] LUCENE-9474: Add back tests.haltonfailure for jenkins compatibility > 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] yonik commented on pull request #1775: SOLR-14767 : fix long field parsing from string
yonik commented on pull request #1775: URL: https://github.com/apache/lucene-solr/pull/1775#issuecomment-678830723 These changes aren't correct... parsing a long as a double (and then converting back to a long) will lose data. A double cannot represent all integral values that a long can. Parsing as a double should only be done as a backup if long parsing fails first. 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-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=17182855#comment-17182855 ] ASF subversion and git services commented on LUCENE-9474: - Commit 5c2e96b5856f8c0471a2b24d2e9488b03f5f8770 in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5c2e96b ] LUCENE-9474: Property "tests.badapples" is missing in Gradle, which is needed for Hoss's statistics. Also Jenkins does not run BadApple tests by default > 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] [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=17182849#comment-17182849
]
Uwe Schindler edited comment on LUCENE-9474 at 8/23/20, 9:22 PM:
-
Hi [~dweiss],
I need your help. With Ant there was {{\-Dtests.haltonfailure=false}}, so the
build completes also some of test fail. But with Gradle I don't get this
working. I tried: If i pass {{--continue}}, it proceeds with other tasks that
did not fail, but it does not run all of them. Also it stops with current test
runners.
I just want to run the tests and let the build continue as normal, so Jenkins
can collect succeeds and failures on its own. So basically, don't care about
failed tests, just execute all of them and don't report a failed build at end
(positive exit code).
Can we restore this in Gradle? Ideally with same property (see "ant
jenkins-hourly").
was (Author: thetaphi):
Hi [~dweiss],
I need your help. With Ant there was {{-Dtests.haltonfailure=false}}, so the
build completes also some of test fail. But with Gradle I don't get this
working. I tried: If i pass {{--continue}}, it proceeds with other tasks that
did not fail, but it does not run all of them. Also it stops with current test
runners.
I just want to run the tests and let the build continue as normal, so Jenkins
can collect succeeds and failures on its own. So basically, don't care about
failed tests, just execute all of them and don't report a failed build at end
(positive exit code).
Can we restore this in Gradle? Ideally with same property (see "ant
jenkins-hourly").
> 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] [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=17182849#comment-17182849
]
Uwe Schindler edited comment on LUCENE-9474 at 8/23/20, 9:21 PM:
-
Hi [~dweiss],
I need your help. With Ant there was {{-Dtests.haltonfailure=false}}, so the
build completes also some of test fail. But with Gradle I don't get this
working. I tried: If i pass {{--continue}}, it proceeds with other tasks that
did not fail, but it does not run all of them. Also it stops with current test
runners.
I just want to run the tests and let the build continue as normal, so Jenkins
can collect succeeds and failures on its own. So basically, don't care about
failed tests, just execute all of them and don't report a failed build at end
(positive exit code).
Can we restore this in Gradle? Ideally with same property (see "ant
jenkins-hourly").
was (Author: thetaphi):
Hi [~dweiss],
I need your help. With Ant there was "-Dtests.haltonfailure=false", so the
build completes also some of test fail. But with Gradle I don't get this
working. I tried: If i pass {{--continue}}, it proceeds with other tasks that
did not fail, but it does not run all
I just want to run the tests and let the build continue as normal, so Jenkins
can collect succeeds and failures on its own. So basically, don't care about
failed tests.
Can we restore this in Gradle? Ideally with same property (see "ant
jenkins-hourly").
> 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-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=17182849#comment-17182849
]
Uwe Schindler commented on LUCENE-9474:
---
Hi [~dweiss],
I need your help. With Ant there was "-Dtests.haltonfailure=false", so the
build completes also some of test fail. But with Gradle I don't get this
working. I tried: If i pass {{--continue}}, it proceeds with other tasks that
did not fail, but it does not run all
I just want to run the tests and let the build continue as normal, so Jenkins
can collect succeeds and failures on its own. So basically, don't care about
failed tests.
Can we restore this in Gradle? Ideally with same property (see "ant
jenkins-hourly").
> 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] [Updated] (LUCENE-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-9475:
--
Description:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven.
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* Move Jenkins over to use Gradle only
** Nightlies
* Verify reference guide build works under Gradle
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
was:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven.
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* Move Jenkins over to use Gradle only
** Nightlies
* Verify reference guide build works under Gradle
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 build which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven.
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * Move Jenkins over to use Gradle only
> ** Nightlies
> * Verify reference guide build works under Gradle
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
> * Remove obsolete files in root dirs of lucene and solr (like
> version.properties, now integrated into gradle)
> * Remove Maven build files (obsolete with Gradle)
> * Hoss's test rollups?
> * Enable javadocs after ant stops being used (LUCENE-9441)
--
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=17182839#comment-17182839 ] ASF subversion and git services commented on LUCENE-9474: - Commit 79f3a1783f511a7f6d7468bc501dec8ac1e29abf in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=79f3a17 ] LUCENE-9474: Easier Jenkins automation, by allowing to pass test JVM args as environment variable (this goes inline with RUNTIME_JAVA_HOME) > 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-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=17182834#comment-17182834 ] ASF subversion and git services commented on LUCENE-9474: - Commit 59736814b65c20357f89db65c8dd670fc8dd4d35 in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5973681 ] LUCENE-9474: Remove bad warning (we sometimes have non-existing directories in classpaths during compile). This warnings is not source-code related so shouldn't be enforced (Java 14) > 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-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=17182828#comment-17182828
]
Uwe Schindler commented on LUCENE-9474:
---
bq. some TODOs are not valid: we can't use jgit to apply that patch - jgit's
apply is broken, see my comment here
All fine, it was more a TODO for myself, as I was searching for "executable" in
all {{*.gradle}} files and I wanted to leave a comment for my later work. If
that does not work with apply, it's bad. I am glad that we do not regenerate on
each run, as this would break on Windows.
> 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] [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=17182828#comment-17182828
]
Uwe Schindler edited comment on LUCENE-9474 at 8/23/20, 7:06 PM:
-
bq. some TODOs are not valid: we can't use jgit to apply that patch - jgit's
apply is broken, see my comment here
All fine, it was more a TODO for myself, as I was searching for "executable" in
all {{*.gradle}} files and I wanted to leave a comment for my later work. If
that does not work with apply, it's bad. I am glad that we do not regenerate on
each run, as this would break on Windows Jenkins (no Git installed, Jenkins
uses JGit internally for checkouts, too).
was (Author: thetaphi):
bq. some TODOs are not valid: we can't use jgit to apply that patch - jgit's
apply is broken, see my comment here
All fine, it was more a TODO for myself, as I was searching for "executable" in
all {{*.gradle}} files and I wanted to leave a comment for my later work. If
that does not work with apply, it's bad. I am glad that we do not regenerate on
each run, as this would break on Windows.
> 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-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=17182827#comment-17182827
]
Uwe Schindler commented on LUCENE-9474:
---
bq. Gradle build from a clean state will work with a single worker (it
generates defaults on the first run but won't pick them up). If you wish to
increase parallelism, you have to set up your CI jobs to pass --max-workers
externally.
The Jenkins nodes have a {{~/lucene.build.properties}} file. I did the same
using {{~/.gradle/gradle.properties}} (copypasting the settings over and adding
the Ant ones, too - like PERL and PYTHON paths on Windows nodes). As the
autogenerated ones have lowest preference (see Gradle docs), the one in user's
home directory take precendence. The Gradle daemon is also - of course -
disabledon Jenkins.
> 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] [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=17182827#comment-17182827
]
Uwe Schindler edited comment on LUCENE-9474 at 8/23/20, 7:04 PM:
-
bq. Gradle build from a clean state will work with a single worker (it
generates defaults on the first run but won't pick them up). If you wish to
increase parallelism, you have to set up your CI jobs to pass --max-workers
externally.
The Jenkins nodes have a {{\~/lucene.build.properties}} file. I did the same
using {{\~/.gradle/gradle.properties}} (copypasting the settings over and
adding the Ant ones, too - like PERL and PYTHON paths on Windows nodes). As the
autogenerated ones have lowest preference (see Gradle docs), the one in user's
home directory take precendence. The Gradle daemon is also - of course -
disabledon Jenkins.
was (Author: thetaphi):
bq. Gradle build from a clean state will work with a single worker (it
generates defaults on the first run but won't pick them up). If you wish to
increase parallelism, you have to set up your CI jobs to pass --max-workers
externally.
The Jenkins nodes have a {{~/lucene.build.properties}} file. I did the same
using {{~/.gradle/gradle.properties}} (copypasting the settings over and adding
the Ant ones, too - like PERL and PYTHON paths on Windows nodes). As the
autogenerated ones have lowest preference (see Gradle docs), the one in user's
home directory take precendence. The Gradle daemon is also - of course -
disabledon Jenkins.
> 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] (SOLR-14726) Streamline getting started experience
[
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182825#comment-17182825
]
Marcus Eagan commented on SOLR-14726:
-
[~arafalov] Whatever committer(s) own the getting developer experience for
developers should seriously consider taking ownership of this problem. V2
implies that the community should use it soon if not now. As someone who is
regularly using the project, it is confusing even for me.
Who is that person, or who are those people?
> Streamline getting started experience
> -
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
> Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Labels: newdev
> Attachments: yasa-http.png
>
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our
> best practices, that should also be followed in production. I have following
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that
> it can be easily executed from Google Colaboratory. Here's an example:
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial
> can be executed from those tools. Except for starting Solr, all other steps
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.),
> configsets from Solr's distribution (instead let the examples refer to them
> from github)
> # Remove the post tool from Solr, curl should suffice.
--
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] (SOLR-14726) Streamline getting started experience
[
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182825#comment-17182825
]
Marcus Eagan edited comment on SOLR-14726 at 8/23/20, 7:01 PM:
---
[~arafalov] Whichever committer(s) own the getting developer experience for
developers should seriously consider taking ownership of this problem. V2
implies that the community should use it soon if not now. As someone who is
regularly using the project, it is confusing even for me.
Who is that person, or who are those people?
was (Author: marcussorealheis):
[~arafalov] Whatever committer(s) own the getting developer experience for
developers should seriously consider taking ownership of this problem. V2
implies that the community should use it soon if not now. As someone who is
regularly using the project, it is confusing even for me.
Who is that person, or who are those people?
> Streamline getting started experience
> -
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
> Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Labels: newdev
> Attachments: yasa-http.png
>
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our
> best practices, that should also be followed in production. I have following
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that
> it can be easily executed from Google Colaboratory. Here's an example:
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial
> can be executed from those tools. Except for starting Solr, all other steps
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.),
> configsets from Solr's distribution (instead let the examples refer to them
> from github)
> # Remove the post tool from Solr, curl should suffice.
--
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=17182824#comment-17182824 ] Uwe Schindler commented on LUCENE-9474: --- bq. My question is: why? I somehow fail to see why a release isn't made from a particular commit (that would have the version number set correctly). It is strange to me - this means the release's git commit would have a snapshot version inside the code? Yes, that was the intention back on some very old discussion. When setting this up, we wanted to make sure that only releases packaged by us have the official "version number", if somebody checks out from git or source file and builds his own version, we wanted to have this a "snapshot" by default. The reason for this was especially people having wrong toolchain (like Java versions, Unicode versions,...). So only official binary builds have the official version number. Nevertheless, we can change this separate, I just replicated what Ant was/is still doing and whats documented in the release documentation for the release manager. The important thing for me is "-Dversion.suffix=", for Jenkins compatibility. > 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] [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=17182806#comment-17182806 ] Dawid Weiss edited comment on LUCENE-9474 at 8/23/20, 6:55 PM: --- I left a few comments on github on this commit, Uwe. I can clean up later; some TODOs are not valid: we can't use jgit to apply that patch - jgit's apply is broken, see my comment here - I did try it: https://github.com/apache/lucene-solr/pull/1262; if you're curious as to why, take a look at this snippet of jgit's apply command: https://github.com/eclipse/jgit/blob/8774f541904ca9afba1786b4da14c1aedf4dda78/org.eclipse.jgit/src/org/eclipse/jgit/api/ApplyCommand.java#L282-L291 was (Author: dweiss): I left a few comments on github on this commit, Uwe. I can clean up later; some TODOs are not valid (we can't use jgit to apply that patch - jgit's apply is broken). > 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-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=17182817#comment-17182817 ] Dawid Weiss commented on LUCENE-9474: - I'm on holidays this week so I may be on and off. Just a few things to remember, perhaps you've done them already. Gradle build from a clean state will work with a single worker (it generates defaults on the first run but won't pick them up). If you wish to increase parallelism, you have to set up your CI jobs to pass --max-workers externally. > 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-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=17182813#comment-17182813 ] Dawid Weiss commented on LUCENE-9474: - bq. allow for release manager to make a release: -Dversion.release=9.0.0 (in the release manage's guide we never commit the version to SVN, we just set Tag. My question is: why? I somehow fail to see why a release isn't made from a particular commit (that would have the version number set correctly). It is strange to me - this means the release's git commit would have a snapshot version inside the code? A release commit doesn't have to be automatically built - it would be enough to create an anonymous commit off a given branch and tag it (this can be done in a number of ways; most easily by creating a local release branch and never pushing it to the repo). > 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-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=17182806#comment-17182806 ] Dawid Weiss commented on LUCENE-9474: - I left a few comments on github on this commit, Uwe. I can clean up later; some TODOs are not valid (we can't use jgit to apply that patch - jgit's apply is broken). > 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-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=17182802#comment-17182802 ] Uwe Schindler commented on LUCENE-9474: --- I also added the same sysprops like ANT to configure external tools, this is important especially for windows jenkins, as those not necessarily have python/perl in path. May need to be configured using Tool-Locations Jenkins plugin. You can now put those files into gradle.properties or pass at command line. > 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-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=17182801#comment-17182801 ] ASF subversion and git services commented on LUCENE-9474: - Commit 494a8a8e04b88f8b4ca8ce1958580ede5ecba538 in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=494a8a8 ] LUCENE-9474: Make external tools configurable like in ant through those sysprops: perl.exe, python3.exe, python2.exe > 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] [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 Two: Process Intro: Section 1: [A Quick Look at the Practical
Process|https://www.dropbox.com/s/96owizh57i5vd8w/Book%20Two%3A%20Process%20Intro%3A%20Section%201%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
## Book Two: Process Intro: Section 2: [A Brief Look at a Few Broad
Problems|https://www.dropbox.com/s/kmkp1lu1tfits1p/Book%20Two%3A%20Process%20Intro%3A%20Section%202%3A%20A%20Brief%20Look%20at%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 3: [Die, Die, Die Solr
XML|https://www.dropbox.com/s/hi452cpjjx1h880/Book%20Two%3A%20Process%20Intro%3A%20Section%203%3A%20Die%2C%20Die%2C%20Die%20Solr%20XML.m4v?dl=0]
## Book Two: Process Intro: Section 4: [Back to a Few Broad
Problems|https://www.dropbox.com/s/tmeayi23p0rmgda/Book%20Two%3A%20Process%20Intro%3A%20Section%204%3A%20Back%20to%20a%20Few%20Broad%20Problems.m4v?dl=0]
### [Book Two: Process Intro: Section 4-2: [Back to a Few Broad Problem
|https://www.dropbox.com/s/1olr1v99t73uoml/Book%20Two%3A%20Process%20Intro%3A%20Section%204-2%3A%20Back%20to%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 6: [Step 5, Own the
World|https://www.dropbox.com/s/usdki6wb1qy6fy9/Book%20Two%3A%20Process%20Intro%3A%20Section%206%3A%20Step%205%2C%20Own%20World.m4v?dl=0]
# 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*:
[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 Two: Process Intro: Section 1: [A Quick Look at the Practical
Process|https://www.dropbox.com/s/96owizh57i5vd8w/Book%20Two%3A%20Process%20Intro%3A%20Section%201%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
## Book Two: Process Intro: Section 2: [A Brief Look at a Few Broad
Problems|https://www.dropbox.com/s/kmkp1lu1tfits1p/Book%20Two%3A%20Process%20Intro%3A%20Section%202%3A%20A%20Brief%20Look%20at%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 3: [Die, Die, Die Solr
XML|https://www.dropbox.com/s/hi452cpjjx1h880/Book%20Two%3A%20Process%20Intro%3A%20Section%203%3A%20Die%2C%20Die%2C%20Die%20Solr%20XML.m4v?dl=0]
## Book Two: Process Intro: Section 4: [Back to a Few Broad
Problems|https://www.dropbox.com/s/tmeayi23p0rmgda/Book%20Two%3A%20Process%20Intro%3A%20Section%204%3A%20Back%20to%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 4-2: [Back to a Few Broad
Problem|https://www.dropbox.com/s/1olr1v99t73uoml/Book%20Two%3A%20Process%20Intro%3A%20Section%204-2%3A%20Back%20to%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 6: [Step 5, Own the
World|https://www.dropbox.com/s/usdki6wb1qy6fy9/Book%20Two%3A%20Process%20Intro%3A%20Section%206%3A%20Step%205%2C%20Own%20World.m4v?dl=0]
# 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*:
[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=17182787#comment-17182787 ] Uwe Schindler edited comment on LUCENE-9474 at 8/23/20, 5:28 PM: - I have some changes to some files to make the build automation working: allow to change version suffix "SNAPSHOT" using sysprop, so Jenkins can include its build number (important for artifacts and javadoc builds): e.g., -Dversion.suffix=jenkins$BUILD_ID allow for release manager to make a release: -Dversion.release=9.0.0 (in the release manage's guide we never commit the version to SVN, we just set Tag. The release manger passes (in ANT) -Dversion, as this is a special prop in Gradle, I changed to -Dversion.release. If somebody has a better idea, tell me! I will just commit this now to master branch, can be changed later. I also committed a fix that Gradlew did not work with whitespace in checkout dir (since a recent change with temporary dirs). was (Author: thetaphi): That's what I am currently testing. I have some changes to some files to make the build automation working: allow to change version suffix "SNAPSHOT" using sysprop, so Jenkins can include its build number (important for artifacts and javadoc builds): e.g., -Dversion.suffix=jenkins$BUILD_ID allow for release manager to make a release: -Dversion.release=9.0.0 (in the release manage's guide we never commit the version to SVN, we just set Tag. The release manger passes (in ANT) -Dversion, as this is a special prop in Gradle, I changed to -Dversion.release. If somebody has a better idea, tell me! I will just commit this now to master branch, can be changed later. I also committed a fix that Gradlew did not work with whitespace in checkout dir (since a recent change with temporary dirs). > 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-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=17182787#comment-17182787 ] Uwe Schindler commented on LUCENE-9474: --- That's what I am currently testing. I have some changes to some files to make the build automation working: allow to change version suffix "SNAPSHOT" using sysprop, so Jenkins can include its build number (important for artifacts and javadoc builds): e.g., -Dversion.suffix=jenkins$BUILD_ID allow for release manager to make a release: -Dversion.release=9.0.0 (in the release manage's guide we never commit the version to SVN, we just set Tag. The release manger passes (in ANT) -Dversion, as this is a special prop in Gradle, I changed to -Dversion.release. If somebody has a better idea, tell me! I will just commit this now to master branch, can be changed later. I also committed a fix that Gradlew did not work with whitespace in checkout dir (since a recent change with temporary dirs). > 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] [Comment Edited] (LUCENE-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182784#comment-17182784
]
Uwe Schindler edited comment on LUCENE-9475 at 8/23/20, 5:27 PM:
-
bq. Verify reference guide build works under Gradle
I think this means that our Jenkins builds work with Gradle.
That's what I am currently testing with Jenkins. I have some changes, see
LUCENE-9474!
was (Author: thetaphi):
bq. Verify reference guide build works under Gradle
I think this means that our Jenkins builds work with Gradle.
That's what I am currently testing. I have some changes to some files to make
the build automation working:
- allow to change version suffix "SNAPSHOT" using sysprop, so Jenkins can
include its build number (important for artifacts and javadoc builds): e.g.,
{{-Dversion.suffix=jenkins$BUILD_ID}}
- allow for release manager to make a release: {{-Dversion.release=9.0.0}} (in
the release manage's guide we never commit the version to SVN, we just set Tag.
The release manger passes (in ANT) {{-Dversion}}, as this is a special prop in
Gradle, I changed to {{-Dversion.release}}. If somebody has a better idea, tell
me! I will just commit this now to master branch, can be changed later.
I also committed a fix that Gradlew did not work with whitespace in checkout
dir (since a recent change with temporary dirs).
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 build which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven.
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * Move Jenkins over to use Gradle only
> ** Nightlies
> * Verify reference guide build works under Gradle
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
> * Remove obsolete files in root dirs of lucene and solr (like
> version.properties, now integrated into gradle)
> * Hoss's test rollups?
> * Enable javadocs after ant stops being used (LUCENE-9441)
--
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=17182786#comment-17182786 ] ASF subversion and git services commented on LUCENE-9474: - Commit ee6cf4c418af8cdc5b10e258df6d77d8a05ffa1f in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ee6cf4c ] LUCENE-9474: Make the version number configurable from outside. This mainly allows Jenkins to set a different suffix than "SNAPSHOT" > 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] [Updated] (LUCENE-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-9475:
--
Description:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven.
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* Move Jenkins over to use Gradle only
** Nightlies
* Verify reference guide build works under Gradle
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
was:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven.
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* Move Jenkins over to use Gradle only
** Nightlies
* Verify reference guide build works under Gradle
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 build which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven.
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * Move Jenkins over to use Gradle only
> ** Nightlies
> * Verify reference guide build works under Gradle
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
> * Remove obsolete files in root dirs of lucene and solr (like
> version.properties, now integrated into gradle)
> * Hoss's test rollups?
> * Enable javadocs after ant stops being used (LUCENE-9441)
--
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-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182784#comment-17182784
]
Uwe Schindler commented on LUCENE-9475:
---
bq. Verify reference guide build works under Gradle
I think this means that our Jenkins builds work with Gradle.
That's what I am currently testing. I have some changes to some files to make
the build automation working:
- allow to change version suffix "SNAPSHOT" using sysprop, so Jenkins can
include its build number (important for artifacts and javadoc builds): e.g.,
{{-Dversion.suffix=jenkins$BUILD_ID}}
- allow for release manager to make a release: {{-Dversion.release=9.0.0}} (in
the release manage's guide we never commit the version to SVN, we just set Tag.
The release manger passes (in ANT) {{-Dversion}}, as this is a special prop in
Gradle, I changed to {{-Dversion.release}}. If somebody has a better idea, tell
me! I will just commit this now to master branch, can be changed later.
I also committed a fix that Gradlew did not work with whitespace in checkout
dir (since a recent change with temporary dirs).
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 build which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven.
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * Move Jenkins over to use Gradle only
> ** Nightlies
> * Verify reference guide build works under Gradle
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * Hoss's test rollups?
> * Enable javadocs after ant stops being used (LUCENE-9441)
--
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
[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 Two: Process Intro: Section 1: [A Quick Look at the Practical
Process|https://www.dropbox.com/s/96owizh57i5vd8w/Book%20Two%3A%20Process%20Intro%3A%20Section%201%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
## Book Two: Process Intro: Section 2: [A Brief Look at a Few Broad
Problems|https://www.dropbox.com/s/kmkp1lu1tfits1p/Book%20Two%3A%20Process%20Intro%3A%20Section%202%3A%20A%20Brief%20Look%20at%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 3: [Die, Die, Die Solr
XML|https://www.dropbox.com/s/hi452cpjjx1h880/Book%20Two%3A%20Process%20Intro%3A%20Section%203%3A%20Die%2C%20Die%2C%20Die%20Solr%20XML.m4v?dl=0]
## Book Two: Process Intro: Section 4: [Back to a Few Broad
Problems|https://www.dropbox.com/s/tmeayi23p0rmgda/Book%20Two%3A%20Process%20Intro%3A%20Section%204%3A%20Back%20to%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 6: [Step 5, Own the
World|https://www.dropbox.com/s/usdki6wb1qy6fy9/Book%20Two%3A%20Process%20Intro%3A%20Section%206%3A%20Step%205%2C%20Own%20World.m4v?dl=0]
# 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*:
[GitHub] [lucene-solr] mikemccand commented on pull request #1623: LUCENE-8962: Merge segments on getReader
mikemccand commented on pull request #1623: URL: https://github.com/apache/lucene-solr/pull/1623#issuecomment-678796112 Hmm, not that I am using the larger (`2000mb`) line docs file, and that might be needed to provoke failure. 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] mikemccand commented on pull request #1623: LUCENE-8962: Merge segments on getReader
mikemccand commented on pull request #1623: URL: https://github.com/apache/lucene-solr/pull/1623#issuecomment-678796020 > @mikemccand I think we are ready here WDYT? +1! Thanks @s1monw! I will continue beasting. The failures are very rare now ... I ran 196 iters of slow + nightly Lucene core + modules tests, and hit only ~4 interesting failures. E.g. this failing seed repros on the PR but not on mainline: ``` org.apache.lucene.index.TestIndexWriterOnVMError > testUnknownError FAILED org.apache.lucene.index.CorruptIndexException: Unexpected file read error while reading index. (resource=BufferedChecksumIndexInput(MockIndexInputWrapper((clone of) ByteBuffersIndexInput (file=pending_segments_2, buffers\ =258 bytes, block size: 1, blocks: 1, position: 0 at __randomizedtesting.SeedInfo.seed([587A104EFE0C57E1:B32CCFCEFC8BC1D1]:0) at org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:300) at org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:521) at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:301) at org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:836) at org.apache.lucene.index.TestIndexWriterOnVMError.doTest(TestIndexWriterOnVMError.java:89) at org.apache.lucene.index.TestIndexWriterOnVMError.testUnknownError(TestIndexWriterOnVMError.java:251) 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:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1754) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:942) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:978) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:370) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:819) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:470) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:951) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:887) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:898) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at
[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 Two: Process Intro: Section 1: [A Quick Look at the Practical
Process|https://www.dropbox.com/s/96owizh57i5vd8w/Book%20Two%3A%20Process%20Intro%3A%20Section%201%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
## Book Two: Process Intro: Section 2: [A Brief Look at a Few Broad
Problems|https://www.dropbox.com/s/kmkp1lu1tfits1p/Book%20Two%3A%20Process%20Intro%3A%20Section%202%3A%20A%20Brief%20Look%20at%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 3: [Die, Die, Die Solr
XML|https://www.dropbox.com/s/hi452cpjjx1h880/Book%20Two%3A%20Process%20Intro%3A%20Section%203%3A%20Die%2C%20Die%2C%20Die%20Solr%20XML.m4v?dl=0]
## Book Two: Process Intro: Section 6: [Step 5, Own the
World|https://www.dropbox.com/s/usdki6wb1qy6fy9/Book%20Two%3A%20Process%20Intro%3A%20Section%206%3A%20Step%205%2C%20Own%20World.m4v?dl=0]
# 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*:
[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 Two: Process Intro: Section 1: [A Quick Look at the Practical
Process|https://www.dropbox.com/s/96owizh57i5vd8w/Book%20Two%3A%20Process%20Intro%3A%20Section%201%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
## Book Two: Process Intro: Section 2: [A Brief Look at a Few Broad
Problems|https://www.dropbox.com/s/kmkp1lu1tfits1p/Book%20Two%3A%20Process%20Intro%3A%20Section%202%3A%20A%20Brief%20Look%20at%20a%20Few%20Broad%20Problems.m4v?dl=0]
## Book Two: Process Intro: Section 3: [Die, Die, Die Solr
XML|https://www.dropbox.com/s/hi452cpjjx1h880/Book%20Two%3A%20Process%20Intro%3A%20Section%203%3A%20Die%2C%20Die%2C%20Die%20Solr%20XML.m4v?dl=0]
## Book Two: Process Intro: Section 6: [Step 5, Own
World|https://www.dropbox.com/s/usdki6wb1qy6fy9/Book%20Two%3A%20Process%20Intro%3A%20Section%206%3A%20Step%205%2C%20Own%20World.m4v?dl=0]
# 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*:
[jira] [Commented] (SOLR-14750) Harden TestBulkSchemaConcurrent
[ https://issues.apache.org/jira/browse/SOLR-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182672#comment-17182672 ] Noble Paul commented on SOLR-14750: --- Yes, I've reopened the original ticket. I'll fix it and close that > 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 20m > 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-14750) Harden TestBulkSchemaConcurrent
[ https://issues.apache.org/jira/browse/SOLR-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182668#comment-17182668 ] Erick Erickson commented on SOLR-14750: --- [~noble.paul] TestPackages.testSchemaPlugins is still @Ignored, is that intentional? > 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 20m > 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] [Comment Edited] (SOLR-14775) Disable metrics collection
[ https://issues.apache.org/jira/browse/SOLR-14775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182662#comment-17182662 ] Ishan Chattopadhyaya edited comment on SOLR-14775 at 8/23/20, 11:33 AM: Ping [~ab], [~dsmiley]. I don't have the expertise to disable it and looking for your help and guidance on this. Feel free to assign this to yourself and fix it. was (Author: ichattopadhyaya): Ping [~ab], [~dsmiley]. I don't have the expertise to disable it and looking for your help and guidance on this. > Disable metrics collection > -- > > Key: SOLR-14775 > URL: https://issues.apache.org/jira/browse/SOLR-14775 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > There is no clean way to disable metrics collection. There are potential > performance issues (as discovered in SOLR-14636) with metrics collection. Let > us build easy switches to disable this. -- 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-14775) Disable metrics collection
[ https://issues.apache.org/jira/browse/SOLR-14775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182662#comment-17182662 ] Ishan Chattopadhyaya commented on SOLR-14775: - Ping [~ab], [~dsmiley]. I don't have the expertise to disable it and looking for your help and guidance on this. > Disable metrics collection > -- > > Key: SOLR-14775 > URL: https://issues.apache.org/jira/browse/SOLR-14775 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > There is no clean way to disable metrics collection. There are potential > performance issues (as discovered in SOLR-14636) with metrics collection. Let > us build easy switches to disable this. -- 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-14775) Disable metrics collection
Ishan Chattopadhyaya created SOLR-14775: --- Summary: Disable metrics collection Key: SOLR-14775 URL: https://issues.apache.org/jira/browse/SOLR-14775 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Ishan Chattopadhyaya There is no clean way to disable metrics collection. There are potential performance issues (as discovered in SOLR-14636) with metrics collection. Let us build easy switches to disable this. -- 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-14651) Metrics history could disable itself better
[ https://issues.apache.org/jira/browse/SOLR-14651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182644#comment-17182644 ] Ishan Chattopadhyaya commented on SOLR-14651: - [~dsmiley], does this need additional ref guide instructions on how to disable metrics history API? > Metrics history could disable itself better > --- > > Key: SOLR-14651 > URL: https://issues.apache.org/jira/browse/SOLR-14651 > Project: Solr > Issue Type: Improvement > Components: metrics >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 8.7 > > Time Spent: 50m > Remaining Estimate: 0h > > The MetricsHistoryHandler should disable itself better than it does. It will > create a SolrRrdBackendFactory (which has an ExecutorService / thread pool) > when it should not when the plugin is disabled. Furthermore, I think this > should be disabled by default in tests, as it's excessive machinery that > don't matter to 99.9% of tests. This will help our tests run more > efficiently. > While working on other issues, I also occasionally saw a thread leak failure > with the RRD being the leaked threads. I see that in "close", we don't > _wait_ for the executor to actually shut down but it should. > CC [~ab] -- 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] munendrasn commented on a change in pull request #1775: SOLR-14767 : fix long field parsing from string
munendrasn commented on a change in pull request #1775:
URL: https://github.com/apache/lucene-solr/pull/1775#discussion_r47518
##
File path: solr/core/src/java/org/apache/solr/schema/TrieLongField.java
##
@@ -56,7 +56,7 @@ public Object toNativeType(Object val) {
if(val==null) return null;
if (val instanceof Number) return ((Number) val).longValue();
try {
- if (val instanceof CharSequence) return Long.parseLong(val.toString());
+ if (val instanceof CharSequence)return (long)
Double.parseDouble(val.toString());
Review comment:
I think we need to check this in createField, not in toNativeType
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] apoorvprecisely opened a new pull request #1775: SOLR-14767 : fix long field parsing from string
apoorvprecisely opened a new pull request #1775: URL: https://github.com/apache/lucene-solr/pull/1775 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] 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. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] 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
[GitHub] [lucene-solr] noblepaul commented on pull request #1756: SOLR-14750: Invoke core reload with core id to avoid multiple reloads
noblepaul commented on pull request #1756: URL: https://github.com/apache/lucene-solr/pull/1756#issuecomment-678751922 it is fixed in #1760 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] noblepaul closed pull request #1756: SOLR-14750: Invoke core reload with core id to avoid multiple reloads
noblepaul closed pull request #1756: URL: https://github.com/apache/lucene-solr/pull/1756 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] mikemccand commented on a change in pull request #1772: LUCENE-9473: Ensure merges are stopped during abort merges
mikemccand commented on a change in pull request #1772:
URL: https://github.com/apache/lucene-solr/pull/1772#discussion_r475177874
##
File path:
lucene/core/src/test/org/apache/lucene/index/TestIndexWriterDelete.java
##
@@ -300,10 +300,11 @@ public void testDeleteAllSimple() throws IOException {
modifier.close();
dir.close();
}
-
+
public void testDeleteAllNoDeadLock() throws IOException,
InterruptedException {
Directory dir = newDirectory();
-final RandomIndexWriter modifier = new RandomIndexWriter(random(), dir);
+final RandomIndexWriter modifier = new RandomIndexWriter(random(), dir,
+newIndexWriterConfig().setMergePolicy(new
MockRandomMergePolicy(random(;
Review comment:
Nice -- this forced `merge-on-getReader/commit` to be used more often in
this test?
##
File path: lucene/core/src/java/org/apache/lucene/index/IndexWriter.java
##
@@ -2427,7 +2426,13 @@ public long deleteAll() throws IOException {
synchronized (this) {
try {
// Abort any running merges
- abortMerges();
+ try {
+abortMerges();
+assert merges.areEnabled() == false : "merges should be
disabled - who enabled them?";
+assert mergingSegments.isEmpty() : "found merging segments but
merges are disabled: " + mergingSegments;
+ } finally {
+merges.enable();
Review comment:
Aha, this is the meat of the change! We need to be able to stop all
running merges, but not prevent new merges.
Maybe add a comment explaining this? The code looks a little odd to
`abortMerges` to only then `merges.enable()` in a `finally` clause. The
`finally` clause is necessary here because on exception we want to be certain
to re-enable merges? An exception during `abortMerges` is not tragic for `IW`
right? I.e. it can resume operations, and maybe not all docs were deleted?
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
