[jira] [Commented] (SOLR-14259) backport SOLR-14013 to Solr 7.7

2020-04-18 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on SOLR-14259:


Commit 6b1263a035cf1ff01c868dac5b32b2421aa74f1f in lucene-solr's branch 
refs/heads/branch_7_7 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6b1263a ]

SOLR-14259: Back port javabin performance regression fixes from SOLR-14013


> backport SOLR-14013 to Solr 7.7
> ---
>
> Key: SOLR-14259
> URL: https://issues.apache.org/jira/browse/SOLR-14259
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.7.3
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>




--
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-14013) javabin performance regressions

2020-04-18 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on SOLR-14013:


Commit 6b1263a035cf1ff01c868dac5b32b2421aa74f1f in lucene-solr's branch 
refs/heads/branch_7_7 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6b1263a ]

SOLR-14259: Back port javabin performance regression fixes from SOLR-14013


> javabin performance regressions
> ---
>
> Key: SOLR-14013
> URL: https://issues.apache.org/jira/browse/SOLR-14013
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 7.7
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Blocker
> Fix For: 8.4
>
> Attachments: SOLR-14013.patch, SOLR-14013.patch, TestQuerySpeed.java, 
> test.json
>
>
> As noted by [~rrockenbaugh] in SOLR-13963, javabin also recently became 
> orders of magnitude slower in certain cases since v7.7.  The cases identified 
> so far include large numbers of values in a field.



--
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-14013) javabin performance regressions

2020-04-18 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on SOLR-14013:


Commit c2cd10b923cf2dca0030f2b1c304038bd8267b4e in lucene-solr's branch 
refs/heads/branch_7_7 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c2cd10b ]

SOLR-14259: Back port javabin performance regression fixes from SOLR-14013


> javabin performance regressions
> ---
>
> Key: SOLR-14013
> URL: https://issues.apache.org/jira/browse/SOLR-14013
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 7.7
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Blocker
> Fix For: 8.4
>
> Attachments: SOLR-14013.patch, SOLR-14013.patch, TestQuerySpeed.java, 
> test.json
>
>
> As noted by [~rrockenbaugh] in SOLR-13963, javabin also recently became 
> orders of magnitude slower in certain cases since v7.7.  The cases identified 
> so far include large numbers of values in a field.



--
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-14259) backport SOLR-14013 to Solr 7.7

2020-04-18 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on SOLR-14259:


Commit c2cd10b923cf2dca0030f2b1c304038bd8267b4e in lucene-solr's branch 
refs/heads/branch_7_7 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c2cd10b ]

SOLR-14259: Back port javabin performance regression fixes from SOLR-14013


> backport SOLR-14013 to Solr 7.7
> ---
>
> Key: SOLR-14259
> URL: https://issues.apache.org/jira/browse/SOLR-14259
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.7.3
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[GitHub] [lucene-solr] s1monw merged pull request #1434: LUCENE-9324: Add an ID to SegmentCommitInfo

2020-04-18 Thread GitBox
s1monw merged pull request #1434: LUCENE-9324: Add an ID to SegmentCommitInfo
URL: https://github.com/apache/lucene-solr/pull/1434
 
 
   


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


With regards,
Apache Git Services

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



[jira] [Commented] (LUCENE-9324) Give IDs to SegmentCommitInfo

2020-04-18 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/LUCENE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17086438#comment-17086438
 ] 

ASF subversion and git services commented on LUCENE-9324:
-

Commit 113043b1ed2ac95de17f6bdd203f6050ff6ca1f7 in lucene-solr's branch 
refs/heads/master from Simon Willnauer
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=113043b ]

LUCENE-9324: Add an ID to SegmentCommitInfo (#1434)

We already have IDs in SegmentInfo, as well as on SegmentInfos which are useful 
to uniquely identify segments and entire commits. Having IDs on 
SegmentCommitInfo is be useful too in
order to compare commits for equality and make snapshots incremental on 
generational files.
This change adds a unique ID to SegmentCommitInfo starting from Lucene 8.6. 
Older segments won't have an ID until the segment receives an update or a 
delete even if they have been opened and / or committed by Lucene 8.6 or above.

> Give IDs to SegmentCommitInfo
> -
>
> Key: LUCENE-9324
> URL: https://issues.apache.org/jira/browse/LUCENE-9324
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: master (9.0), 8.6
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> We already have IDs in SegmentInfo, which are useful to uniquely identify 
> segments. Having IDs on SegmentCommitInfo would be useful too in order to 
> compare commits for equality and make snapshots incremental on generational 
> files too.



--
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] jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents

2020-04-18 Thread GitBox
jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to 
skip noncompetitive documents
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r410691342
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/Weight.java
 ##
 @@ -201,19 +202,20 @@ public long cost() {
 @Override
 public int score(LeafCollector collector, Bits acceptDocs, int min, int 
max) throws IOException {
   collector.setScorer(scorer);
+  DocIdSetIterator scorerIterator = twoPhase == null? iterator : 
twoPhase.approximation();
 
 Review comment:
   ```suggestion
 DocIdSetIterator scorerIterator = twoPhase == null ? iterator : 
twoPhase.approximation();
   ```


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


With regards,
Apache Git Services

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



[GitHub] [lucene-solr] jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents

2020-04-18 Thread GitBox
jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to 
skip noncompetitive documents
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r410692812
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/search/FilteringFieldComparator.java
 ##
 @@ -0,0 +1,350 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.search;
+
+import org.apache.lucene.document.LongPoint;
+import org.apache.lucene.document.IntPoint;
+import org.apache.lucene.document.DoublePoint;
+import org.apache.lucene.document.FloatPoint;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PointValues;
+import org.apache.lucene.util.DocIdSetBuilder;
+
+import java.io.IOException;
+import java.util.Arrays;
+
+/**
+ * Decorates a wrapped FieldComparator to add a functionality to skip over 
non-competitive docs.
+ * FilteringFieldComparator provides two additional functions for a 
FieldComparator:
+ * 1) {@code competitiveIterator()} that returns an iterator over
+ *  competitive docs that are stronger than already collected docs.
+ * 2) {@code setCanUpdateIterator()} that notifies the comparator when it is 
ok to start updating its internal iterator.
+ *  This method is called from a collector to inform the comparator to start 
updating its iterator.
+ */
+public abstract class FilteringFieldComparator extends FieldComparator {
+final FieldComparator in;
+protected DocIdSetIterator iterator = null;
+
+public FilteringFieldComparator(FieldComparator in) {
+this.in = in;
+}
+
+protected abstract void setCanUpdateIterator() throws IOException;
+
+@Override
+public int compare(int slot1, int slot2) {
+return in.compare(slot1, slot2);
+}
+
+@Override
+public T value(int slot) {
+return in.value(slot);
+}
+
+@Override
+public void setTopValue(T value) {
+in.setTopValue(value);
+}
+
+@Override
+public int compareValues(T first, T second) {
+return in.compareValues(first, second);
+}
+
+/**
+ * Returns an iterator over competitive documents
+ */
+public DocIdSetIterator competitiveIterator() {
+if (iterator == null) return null;
+return new DocIdSetIterator() {
+private int doc;
+@Override
+public int nextDoc() throws IOException {
+return doc = iterator.nextDoc();
+}
+
+@Override
+public int docID() {
+return doc;
+}
+
+@Override
+public long cost() {
+return iterator.cost();
+}
+
+@Override
+public int advance(int target) throws IOException {
+return doc = iterator.advance(target);
+}
+};
+}
+
+/**
+ * Try to wrap a given field comparator to add to it a functionality to 
skip over non-competitive docs.
+ * If for the given comparator the skip functionality is not implemented, 
return the comparator itself.
+ */
+public static FieldComparator 
wrapToFilteringComparator(FieldComparator comparator, boolean reverse) {
+if (comparator instanceof FieldComparator.LongComparator){
+return new 
FilteringFieldComparator.FilteringLongComparator((FieldComparator.LongComparator)
 comparator, reverse);
+}
+if (comparator instanceof FieldComparator.IntComparator){
+return new 
FilteringFieldComparator.FilteringIntComparator((FieldComparator.IntComparator) 
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.DoubleComparator){
+return new 
FilteringFieldComparator.FilteringDoubleComparator((FieldComparator.DoubleComparator)
 comparator, reverse);
+}
+if (comparator instanceof FieldComparator.FloatComparator){
+return new 
FilteringFieldComparator.FilteringFloatComparator((FieldComparator.FloatComparator)
 comparator, reverse);
+}
+return comparator;
+}
+
+/**
+ * A wrapper over {@code NumericComparator} that adds a functionality to 
filter non-competitive docs.
+

[GitHub] [lucene-solr] jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents

2020-04-18 Thread GitBox
jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to 
skip noncompetitive documents
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r410688437
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/search/FilteringFieldComparator.java
 ##
 @@ -0,0 +1,350 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.search;
+
+import org.apache.lucene.document.LongPoint;
+import org.apache.lucene.document.IntPoint;
+import org.apache.lucene.document.DoublePoint;
+import org.apache.lucene.document.FloatPoint;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PointValues;
+import org.apache.lucene.util.DocIdSetBuilder;
+
+import java.io.IOException;
+import java.util.Arrays;
+
+/**
+ * Decorates a wrapped FieldComparator to add a functionality to skip over 
non-competitive docs.
+ * FilteringFieldComparator provides two additional functions for a 
FieldComparator:
+ * 1) {@code competitiveIterator()} that returns an iterator over
+ *  competitive docs that are stronger than already collected docs.
+ * 2) {@code setCanUpdateIterator()} that notifies the comparator when it is 
ok to start updating its internal iterator.
+ *  This method is called from a collector to inform the comparator to start 
updating its iterator.
+ */
+public abstract class FilteringFieldComparator extends FieldComparator {
+final FieldComparator in;
+protected DocIdSetIterator iterator = null;
+
+public FilteringFieldComparator(FieldComparator in) {
+this.in = in;
+}
+
+protected abstract void setCanUpdateIterator() throws IOException;
+
+@Override
+public int compare(int slot1, int slot2) {
+return in.compare(slot1, slot2);
+}
+
+@Override
+public T value(int slot) {
+return in.value(slot);
+}
+
+@Override
+public void setTopValue(T value) {
+in.setTopValue(value);
+}
+
+@Override
+public int compareValues(T first, T second) {
+return in.compareValues(first, second);
+}
+
+/**
+ * Returns an iterator over competitive documents
+ */
+public DocIdSetIterator competitiveIterator() {
+if (iterator == null) return null;
+return new DocIdSetIterator() {
+private int doc;
+@Override
+public int nextDoc() throws IOException {
+return doc = iterator.nextDoc();
+}
+
+@Override
+public int docID() {
+return doc;
+}
+
+@Override
+public long cost() {
+return iterator.cost();
+}
+
+@Override
+public int advance(int target) throws IOException {
+return doc = iterator.advance(target);
+}
+};
+}
+
+/**
+ * Try to wrap a given field comparator to add to it a functionality to 
skip over non-competitive docs.
+ * If for the given comparator the skip functionality is not implemented, 
return the comparator itself.
+ */
+public static FieldComparator 
wrapToFilteringComparator(FieldComparator comparator, boolean reverse) {
+if (comparator instanceof FieldComparator.LongComparator){
+return new 
FilteringFieldComparator.FilteringLongComparator((FieldComparator.LongComparator)
 comparator, reverse);
+}
+if (comparator instanceof FieldComparator.IntComparator){
+return new 
FilteringFieldComparator.FilteringIntComparator((FieldComparator.IntComparator) 
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.DoubleComparator){
+return new 
FilteringFieldComparator.FilteringDoubleComparator((FieldComparator.DoubleComparator)
 comparator, reverse);
+}
+if (comparator instanceof FieldComparator.FloatComparator){
+return new 
FilteringFieldComparator.FilteringFloatComparator((FieldComparator.FloatComparator)
 comparator, reverse);
+}
+return comparator;
+}
+
+/**
+ * A wrapper over {@code NumericComparator} that adds a functionality to 
filter non-competitive docs.
+

[GitHub] [lucene-solr] jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents

2020-04-18 Thread GitBox
jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to 
skip noncompetitive documents
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r410690894
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/ScoreMode.java
 ##
 @@ -24,37 +24,53 @@
   /**
* Produced scorers will allow visiting all matches and get their score.
*/
-  COMPLETE {
-@Override
-public boolean needsScores() {
-  return true;
-}
-  },
+  COMPLETE(true, true),
 
   /**
* Produced scorers will allow visiting all matches but scores won't be
* available.
*/
-  COMPLETE_NO_SCORES {
-@Override
-public boolean needsScores() {
-  return false;
-}
-  },
+  COMPLETE_NO_SCORES(true, false),
 
   /**
* Produced scorers will optionally allow skipping over non-competitive
* hits using the {@link Scorer#setMinCompetitiveScore(float)} API.
*/
-  TOP_SCORES {
-@Override
-public boolean needsScores() {
-  return true;
-}
-  };
+  TOP_SCORES(false, true),
+
+  /**
+   * ScoreMode for top field collectors that can provide their own iterators,
+   * to optionally allow to skip for non-competitive docs
+   */
+  TOP_DOCS(false, false),
+
+  /**
+   * ScoreMode for top field collectors that can provide their own iterators,
+   * to optionally allow to skip for non-competitive docs.
+   * This mode is used when there is a secondary sort by _score.
+   */
+  TOP_DOCS_WITH_SCORES(false, true);
 
 Review comment:
   We need both because the first one sorts by score first and should use e.g. 
block-max WAND while the latter sorts by field so block-max WAND isn't 
relevant, but we still need to disable bulk scoring. `needsScores` and 
`isExhaustive` are not complete descriptions of these enum constants.


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


With regards,
Apache Git Services

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



[GitHub] [lucene-solr] jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents

2020-04-18 Thread GitBox
jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to 
skip noncompetitive documents
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r410690540
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/search/FilteringFieldComparator.java
 ##
 @@ -0,0 +1,350 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.search;
+
+import org.apache.lucene.document.LongPoint;
+import org.apache.lucene.document.IntPoint;
+import org.apache.lucene.document.DoublePoint;
+import org.apache.lucene.document.FloatPoint;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PointValues;
+import org.apache.lucene.util.DocIdSetBuilder;
+
+import java.io.IOException;
+import java.util.Arrays;
+
+/**
+ * Decorates a wrapped FieldComparator to add a functionality to skip over 
non-competitive docs.
+ * FilteringFieldComparator provides two additional functions for a 
FieldComparator:
+ * 1) {@code competitiveIterator()} that returns an iterator over
+ *  competitive docs that are stronger than already collected docs.
+ * 2) {@code setCanUpdateIterator()} that notifies the comparator when it is 
ok to start updating its internal iterator.
+ *  This method is called from a collector to inform the comparator to start 
updating its iterator.
+ */
+public abstract class FilteringFieldComparator extends FieldComparator {
+final FieldComparator in;
+protected DocIdSetIterator iterator = null;
+
+public FilteringFieldComparator(FieldComparator in) {
+this.in = in;
+}
+
+protected abstract void setCanUpdateIterator() throws IOException;
+
+@Override
+public int compare(int slot1, int slot2) {
+return in.compare(slot1, slot2);
+}
+
+@Override
+public T value(int slot) {
+return in.value(slot);
+}
+
+@Override
+public void setTopValue(T value) {
+in.setTopValue(value);
+}
+
+@Override
+public int compareValues(T first, T second) {
+return in.compareValues(first, second);
+}
+
+/**
+ * Returns an iterator over competitive documents
+ */
+public DocIdSetIterator competitiveIterator() {
+if (iterator == null) return null;
+return new DocIdSetIterator() {
+private int doc;
+@Override
+public int nextDoc() throws IOException {
+return doc = iterator.nextDoc();
+}
+
+@Override
+public int docID() {
+return doc;
+}
+
+@Override
+public long cost() {
+return iterator.cost();
+}
+
+@Override
+public int advance(int target) throws IOException {
+return doc = iterator.advance(target);
+}
+};
+}
+
+/**
+ * Try to wrap a given field comparator to add to it a functionality to 
skip over non-competitive docs.
+ * If for the given comparator the skip functionality is not implemented, 
return the comparator itself.
+ */
+public static FieldComparator 
wrapToFilteringComparator(FieldComparator comparator, boolean reverse) {
+if (comparator instanceof FieldComparator.LongComparator){
+return new 
FilteringFieldComparator.FilteringLongComparator((FieldComparator.LongComparator)
 comparator, reverse);
+}
+if (comparator instanceof FieldComparator.IntComparator){
+return new 
FilteringFieldComparator.FilteringIntComparator((FieldComparator.IntComparator) 
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.DoubleComparator){
+return new 
FilteringFieldComparator.FilteringDoubleComparator((FieldComparator.DoubleComparator)
 comparator, reverse);
+}
+if (comparator instanceof FieldComparator.FloatComparator){
+return new 
FilteringFieldComparator.FilteringFloatComparator((FieldComparator.FloatComparator)
 comparator, reverse);
+}
+return comparator;
+}
+
+/**
+ * A wrapper over {@code NumericComparator} that adds a functionality to 
filter non-competitive docs.
+

[GitHub] [lucene-solr] jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents

2020-04-18 Thread GitBox
jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to 
skip noncompetitive documents
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r410688678
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
 ##
 @@ -432,7 +461,9 @@ static TopFieldCollector create(Sort sort, int numHits, 
FieldDoc after,
   throw new IllegalArgumentException("hitsThresholdChecker should not be 
null");
 }
 
-FieldValueHitQueue queue = FieldValueHitQueue.create(sort.fields, 
numHits);
+// here we assume that if hitsThreshold was set, we let a comparator to 
skip non-competitive docs
+boolean filterNonCompetitveDocs = hitsThresholdChecker.getHitsThreshold() 
== Integer.MAX_VALUE ? false : true;
 
 Review comment:
   ```suggestion
   boolean filterNonCompetitiveDocs = 
hitsThresholdChecker.getHitsThreshold() == Integer.MAX_VALUE ? false : true;
   ```


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


With regards,
Apache Git Services

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



[GitHub] [lucene-solr] jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents

2020-04-18 Thread GitBox
jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to 
skip noncompetitive documents
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r410690396
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/search/FilteringFieldComparator.java
 ##
 @@ -0,0 +1,350 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.search;
+
+import org.apache.lucene.document.LongPoint;
+import org.apache.lucene.document.IntPoint;
+import org.apache.lucene.document.DoublePoint;
+import org.apache.lucene.document.FloatPoint;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PointValues;
+import org.apache.lucene.util.DocIdSetBuilder;
+
+import java.io.IOException;
+import java.util.Arrays;
+
+/**
+ * Decorates a wrapped FieldComparator to add a functionality to skip over 
non-competitive docs.
+ * FilteringFieldComparator provides two additional functions for a 
FieldComparator:
+ * 1) {@code competitiveIterator()} that returns an iterator over
+ *  competitive docs that are stronger than already collected docs.
+ * 2) {@code setCanUpdateIterator()} that notifies the comparator when it is 
ok to start updating its internal iterator.
+ *  This method is called from a collector to inform the comparator to start 
updating its iterator.
+ */
+public abstract class FilteringFieldComparator extends FieldComparator {
+final FieldComparator in;
+protected DocIdSetIterator iterator = null;
+
+public FilteringFieldComparator(FieldComparator in) {
+this.in = in;
+}
+
+protected abstract void setCanUpdateIterator() throws IOException;
+
+@Override
+public int compare(int slot1, int slot2) {
+return in.compare(slot1, slot2);
+}
+
+@Override
+public T value(int slot) {
+return in.value(slot);
+}
+
+@Override
+public void setTopValue(T value) {
+in.setTopValue(value);
+}
+
+@Override
+public int compareValues(T first, T second) {
+return in.compareValues(first, second);
+}
+
+/**
+ * Returns an iterator over competitive documents
+ */
+public DocIdSetIterator competitiveIterator() {
+if (iterator == null) return null;
+return new DocIdSetIterator() {
+private int doc;
+@Override
+public int nextDoc() throws IOException {
+return doc = iterator.nextDoc();
+}
+
+@Override
+public int docID() {
+return doc;
+}
+
+@Override
+public long cost() {
+return iterator.cost();
+}
+
+@Override
+public int advance(int target) throws IOException {
+return doc = iterator.advance(target);
+}
+};
+}
+
+/**
+ * Try to wrap a given field comparator to add to it a functionality to 
skip over non-competitive docs.
+ * If for the given comparator the skip functionality is not implemented, 
return the comparator itself.
+ */
+public static FieldComparator 
wrapToFilteringComparator(FieldComparator comparator, boolean reverse) {
+if (comparator instanceof FieldComparator.LongComparator){
+return new 
FilteringFieldComparator.FilteringLongComparator((FieldComparator.LongComparator)
 comparator, reverse);
+}
+if (comparator instanceof FieldComparator.IntComparator){
+return new 
FilteringFieldComparator.FilteringIntComparator((FieldComparator.IntComparator) 
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.DoubleComparator){
+return new 
FilteringFieldComparator.FilteringDoubleComparator((FieldComparator.DoubleComparator)
 comparator, reverse);
+}
+if (comparator instanceof FieldComparator.FloatComparator){
+return new 
FilteringFieldComparator.FilteringFloatComparator((FieldComparator.FloatComparator)
 comparator, reverse);
+}
+return comparator;
+}
+
+/**
+ * A wrapper over {@code NumericComparator} that adds a functionality to 
filter non-competitive docs.
+

[GitHub] [lucene-solr] jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents

2020-04-18 Thread GitBox
jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to 
skip noncompetitive documents
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r410689886
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/search/FilteringFieldComparator.java
 ##
 @@ -0,0 +1,350 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.search;
+
+import org.apache.lucene.document.LongPoint;
+import org.apache.lucene.document.IntPoint;
+import org.apache.lucene.document.DoublePoint;
+import org.apache.lucene.document.FloatPoint;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PointValues;
+import org.apache.lucene.util.DocIdSetBuilder;
+
+import java.io.IOException;
+import java.util.Arrays;
+
+/**
+ * Decorates a wrapped FieldComparator to add a functionality to skip over 
non-competitive docs.
+ * FilteringFieldComparator provides two additional functions for a 
FieldComparator:
+ * 1) {@code competitiveIterator()} that returns an iterator over
+ *  competitive docs that are stronger than already collected docs.
+ * 2) {@code setCanUpdateIterator()} that notifies the comparator when it is 
ok to start updating its internal iterator.
+ *  This method is called from a collector to inform the comparator to start 
updating its iterator.
+ */
+public abstract class FilteringFieldComparator extends FieldComparator {
+final FieldComparator in;
+protected DocIdSetIterator iterator = null;
+
+public FilteringFieldComparator(FieldComparator in) {
+this.in = in;
+}
+
+protected abstract void setCanUpdateIterator() throws IOException;
+
+@Override
+public int compare(int slot1, int slot2) {
+return in.compare(slot1, slot2);
+}
+
+@Override
+public T value(int slot) {
+return in.value(slot);
+}
+
+@Override
+public void setTopValue(T value) {
+in.setTopValue(value);
+}
+
+@Override
+public int compareValues(T first, T second) {
+return in.compareValues(first, second);
+}
+
+/**
+ * Returns an iterator over competitive documents
+ */
+public DocIdSetIterator competitiveIterator() {
+if (iterator == null) return null;
+return new DocIdSetIterator() {
+private int doc;
+@Override
+public int nextDoc() throws IOException {
+return doc = iterator.nextDoc();
+}
+
+@Override
+public int docID() {
+return doc;
+}
+
+@Override
+public long cost() {
+return iterator.cost();
+}
+
+@Override
+public int advance(int target) throws IOException {
+return doc = iterator.advance(target);
+}
+};
+}
+
+/**
+ * Try to wrap a given field comparator to add to it a functionality to 
skip over non-competitive docs.
+ * If for the given comparator the skip functionality is not implemented, 
return the comparator itself.
+ */
+public static FieldComparator 
wrapToFilteringComparator(FieldComparator comparator, boolean reverse) {
+if (comparator instanceof FieldComparator.LongComparator){
+return new 
FilteringFieldComparator.FilteringLongComparator((FieldComparator.LongComparator)
 comparator, reverse);
+}
+if (comparator instanceof FieldComparator.IntComparator){
+return new 
FilteringFieldComparator.FilteringIntComparator((FieldComparator.IntComparator) 
comparator, reverse);
+}
+if (comparator instanceof FieldComparator.DoubleComparator){
+return new 
FilteringFieldComparator.FilteringDoubleComparator((FieldComparator.DoubleComparator)
 comparator, reverse);
+}
+if (comparator instanceof FieldComparator.FloatComparator){
+return new 
FilteringFieldComparator.FilteringFloatComparator((FieldComparator.FloatComparator)
 comparator, reverse);
+}
+return comparator;
+}
+
+/**
+ * A wrapper over {@code NumericComparator} that adds a functionality to 
filter non-competitive docs.
+

[GitHub] [lucene-solr] jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents

2020-04-18 Thread GitBox
jpountz commented on a change in pull request #1351: LUCENE-9280: Collectors to 
skip noncompetitive documents
URL: https://github.com/apache/lucene-solr/pull/1351#discussion_r410688181
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/search/FilteringFieldComparator.java
 ##
 @@ -0,0 +1,350 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.search;
+
+import org.apache.lucene.document.LongPoint;
+import org.apache.lucene.document.IntPoint;
+import org.apache.lucene.document.DoublePoint;
+import org.apache.lucene.document.FloatPoint;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PointValues;
+import org.apache.lucene.util.DocIdSetBuilder;
+
+import java.io.IOException;
+import java.util.Arrays;
+
+/**
+ * Decorates a wrapped FieldComparator to add a functionality to skip over 
non-competitive docs.
+ * FilteringFieldComparator provides two additional functions for a 
FieldComparator:
+ * 1) {@code competitiveIterator()} that returns an iterator over
+ *  competitive docs that are stronger than already collected docs.
+ * 2) {@code setCanUpdateIterator()} that notifies the comparator when it is 
ok to start updating its internal iterator.
+ *  This method is called from a collector to inform the comparator to start 
updating its iterator.
+ */
+public abstract class FilteringFieldComparator extends FieldComparator {
+final FieldComparator in;
+protected DocIdSetIterator iterator = null;
 
 Review comment:
   It feels wrong to have an iterator - which is a per-segment object - on a 
FieldComparator - which is a top-level object. Can we only have it on the 
LeafComparator?


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


With regards,
Apache Git Services

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



[jira] [Commented] (LUCENE-9324) Give IDs to SegmentCommitInfo

2020-04-18 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/LUCENE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17086441#comment-17086441
 ] 

ASF subversion and git services commented on LUCENE-9324:
-

Commit 2d63a9d1208bbf950135b90496268b0a40e119b5 in lucene-solr's branch 
refs/heads/branch_8x from Simon Willnauer
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2d63a9d ]

LUCENE-9324: Add an ID to SegmentCommitInfo (#1434)

We already have IDs in SegmentInfo, as well as on SegmentInfos which are useful
to uniquely identify segments and entire commits. Having IDs on
SegmentCommitInfo is be useful too in order to compare commits for equality and
make snapshots incremental on generational files.  This change adds a unique ID
to SegmentCommitInfo starting from Lucene 8.6. Older segments won't have an ID
until the segment receives an update or a delete even if they have been opened
and / or committed by Lucene 8.6 or above.


> Give IDs to SegmentCommitInfo
> -
>
> Key: LUCENE-9324
> URL: https://issues.apache.org/jira/browse/LUCENE-9324
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: master (9.0), 8.6
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> We already have IDs in SegmentInfo, which are useful to uniquely identify 
> segments. Having IDs on SegmentCommitInfo would be useful too in order to 
> compare commits for equality and make snapshots incremental on generational 
> files too.



--
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] (LUCENE-9324) Give IDs to SegmentCommitInfo

2020-04-18 Thread Simon Willnauer (Jira)


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

Simon Willnauer resolved LUCENE-9324.
-
Lucene Fields: New,Patch Available  (was: New)
   Resolution: Fixed

> Give IDs to SegmentCommitInfo
> -
>
> Key: LUCENE-9324
> URL: https://issues.apache.org/jira/browse/LUCENE-9324
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: master (9.0), 8.6
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> We already have IDs in SegmentInfo, which are useful to uniquely identify 
> segments. Having IDs on SegmentCommitInfo would be useful too in order to 
> compare commits for equality and make snapshots incremental on generational 
> files too.



--
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-14414) New Admin UI

2020-04-18 Thread Marcus Eagan (Jira)
Marcus Eagan created SOLR-14414:
---

 Summary: New Admin UI
 Key: SOLR-14414
 URL: https://issues.apache.org/jira/browse/SOLR-14414
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Admin UI
Affects Versions: master (9.0)
Reporter: Marcus Eagan






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Assigned] (SOLR-13886) HDFSSyncSliceTest and SyncSliceTest started failing frequently

2020-04-18 Thread Kevin Risden (Jira)


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

Kevin Risden reassigned SOLR-13886:
---

Assignee: Kevin Risden

> HDFSSyncSliceTest and SyncSliceTest started failing frequently
> --
>
> Key: SOLR-13886
> URL: https://issues.apache.org/jira/browse/SOLR-13886
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Kevin Risden
>Priority: Major
>
> While I can see some failures of this test in the past, they weren't frequent 
> and were usually things like port bindings (maybe SOLR-13871) or timeouts. 
> I've started this failure in Jenkins (and locally) frequently:
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5410/
> Java: 64bit/jdk-13 -XX:-UseCompressedOops -XX:+UseParallelGC
> 2 tests failed.
> FAILED:  org.apache.solr.cloud.SyncSliceTest.test
> Error Message:
> expected:<5> but was:<4>
> Stack Trace:
> java.lang.AssertionError: expected:<5> but was:<4>
> at 
> __randomizedtesting.SeedInfo.seed([F8E3B768E16E848D:70B788B24F92E975]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at org.apache.solr.cloud.SyncSliceTest.test(SyncSliceTest.java:150)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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(NoShadowingOrOverr

[jira] [Updated] (SOLR-13886) HDFSSyncSliceTest and SyncSliceTest started failing frequently

2020-04-18 Thread Kevin Risden (Jira)


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

Kevin Risden updated SOLR-13886:

Summary: HDFSSyncSliceTest and SyncSliceTest started failing frequently  
(was: SyncSliceTest started failing frequently)

> HDFSSyncSliceTest and SyncSliceTest started failing frequently
> --
>
> Key: SOLR-13886
> URL: https://issues.apache.org/jira/browse/SOLR-13886
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Major
>
> While I can see some failures of this test in the past, they weren't frequent 
> and were usually things like port bindings (maybe SOLR-13871) or timeouts. 
> I've started this failure in Jenkins (and locally) frequently:
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5410/
> Java: 64bit/jdk-13 -XX:-UseCompressedOops -XX:+UseParallelGC
> 2 tests failed.
> FAILED:  org.apache.solr.cloud.SyncSliceTest.test
> Error Message:
> expected:<5> but was:<4>
> Stack Trace:
> java.lang.AssertionError: expected:<5> but was:<4>
> at 
> __randomizedtesting.SeedInfo.seed([F8E3B768E16E848D:70B788B24F92E975]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at org.apache.solr.cloud.SyncSliceTest.test(SyncSliceTest.java:150)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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.NoShadowi

[jira] [Closed] (SOLR-4644) SyncSliceTest often fails trying to setup an inconsistent state, generally only on Apache Jenkins.

2020-04-18 Thread Kevin Risden (Jira)


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

Kevin Risden closed SOLR-4644.
--

> SyncSliceTest often fails trying to setup an inconsistent state, generally 
> only on Apache Jenkins.
> --
>
> Key: SOLR-4644
> URL: https://issues.apache.org/jira/browse/SOLR-4644
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: 4.9, 6.0
>
>
> java.lang.AssertionError: Test Setup Failure: shard1 should have just been 
> set up to be inconsistent - but it's still consistent. 
> Leader:http://127.0.0.1:58076/gj_mz/in/collection1 Dead 
> Guy:http://127.0.0.1:64555/gj_mz/in/collection1skip list:[CloudJettyRunner 
> [url=http://127.0.0.1:18606/gj_mz/in/collection1], CloudJettyRunner 
> [url=http://127.0.0.1:10847/gj_mz/in/collection1]]



--
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-4644) SyncSliceTest often fails trying to setup an inconsistent state, generally only on Apache Jenkins.

2020-04-18 Thread Kevin Risden (Jira)


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

Kevin Risden resolved SOLR-4644.

Resolution: Fixed

Marking this as fixed since it hasn't been happening lately. SOLR-13886 has 
been happening instead and will fix that there.

> SyncSliceTest often fails trying to setup an inconsistent state, generally 
> only on Apache Jenkins.
> --
>
> Key: SOLR-4644
> URL: https://issues.apache.org/jira/browse/SOLR-4644
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: 6.0, 4.9
>
>
> java.lang.AssertionError: Test Setup Failure: shard1 should have just been 
> set up to be inconsistent - but it's still consistent. 
> Leader:http://127.0.0.1:58076/gj_mz/in/collection1 Dead 
> Guy:http://127.0.0.1:64555/gj_mz/in/collection1skip list:[CloudJettyRunner 
> [url=http://127.0.0.1:18606/gj_mz/in/collection1], CloudJettyRunner 
> [url=http://127.0.0.1:10847/gj_mz/in/collection1]]



--
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-4644) SyncSliceTest often fails trying to setup an inconsistent state, generally only on Apache Jenkins.

2020-04-18 Thread Kevin Risden (Jira)


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

Kevin Risden updated SOLR-4644:
---
Fix Version/s: (was: 6.0)
   (was: 4.9)

> SyncSliceTest often fails trying to setup an inconsistent state, generally 
> only on Apache Jenkins.
> --
>
> Key: SOLR-4644
> URL: https://issues.apache.org/jira/browse/SOLR-4644
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> java.lang.AssertionError: Test Setup Failure: shard1 should have just been 
> set up to be inconsistent - but it's still consistent. 
> Leader:http://127.0.0.1:58076/gj_mz/in/collection1 Dead 
> Guy:http://127.0.0.1:64555/gj_mz/in/collection1skip list:[CloudJettyRunner 
> [url=http://127.0.0.1:18606/gj_mz/in/collection1], CloudJettyRunner 
> [url=http://127.0.0.1:10847/gj_mz/in/collection1]]



--
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-13886) HDFSSyncSliceTest and SyncSliceTest started failing frequently

2020-04-18 Thread Kevin Risden (Jira)


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

Kevin Risden commented on SOLR-13886:
-

HDFSSyncSliceTest started failing the exact same way as this. I looked into it 
and it looks like a race condition with the test not committing. The newly 
added document isn't available without the commit so the check fails to find 
it. 

> HDFSSyncSliceTest and SyncSliceTest started failing frequently
> --
>
> Key: SOLR-13886
> URL: https://issues.apache.org/jira/browse/SOLR-13886
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Kevin Risden
>Priority: Major
>
> While I can see some failures of this test in the past, they weren't frequent 
> and were usually things like port bindings (maybe SOLR-13871) or timeouts. 
> I've started this failure in Jenkins (and locally) frequently:
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5410/
> Java: 64bit/jdk-13 -XX:-UseCompressedOops -XX:+UseParallelGC
> 2 tests failed.
> FAILED:  org.apache.solr.cloud.SyncSliceTest.test
> Error Message:
> expected:<5> but was:<4>
> Stack Trace:
> java.lang.AssertionError: expected:<5> but was:<4>
> at 
> __randomizedtesting.SeedInfo.seed([F8E3B768E16E848D:70B788B24F92E975]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at org.apache.solr.cloud.SyncSliceTest.test(SyncSliceTest.java:150)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter

[jira] [Updated] (SOLR-13886) HDFSSyncSliceTest and SyncSliceTest started failing frequently

2020-04-18 Thread Kevin Risden (Jira)


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

Kevin Risden updated SOLR-13886:

Attachment: SOLR-13886.patch

> HDFSSyncSliceTest and SyncSliceTest started failing frequently
> --
>
> Key: SOLR-13886
> URL: https://issues.apache.org/jira/browse/SOLR-13886
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-13886.patch
>
>
> While I can see some failures of this test in the past, they weren't frequent 
> and were usually things like port bindings (maybe SOLR-13871) or timeouts. 
> I've started this failure in Jenkins (and locally) frequently:
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5410/
> Java: 64bit/jdk-13 -XX:-UseCompressedOops -XX:+UseParallelGC
> 2 tests failed.
> FAILED:  org.apache.solr.cloud.SyncSliceTest.test
> Error Message:
> expected:<5> but was:<4>
> Stack Trace:
> java.lang.AssertionError: expected:<5> but was:<4>
> at 
> __randomizedtesting.SeedInfo.seed([F8E3B768E16E848D:70B788B24F92E975]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at org.apache.solr.cloud.SyncSliceTest.test(SyncSliceTest.java:150)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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.NoShadowingOrOverridesOn

[jira] [Updated] (SOLR-13886) HDFSSyncSliceTest and SyncSliceTest started failing frequently

2020-04-18 Thread Kevin Risden (Jira)


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

Kevin Risden updated SOLR-13886:

Status: Patch Available  (was: Open)

> HDFSSyncSliceTest and SyncSliceTest started failing frequently
> --
>
> Key: SOLR-13886
> URL: https://issues.apache.org/jira/browse/SOLR-13886
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-13886.patch
>
>
> While I can see some failures of this test in the past, they weren't frequent 
> and were usually things like port bindings (maybe SOLR-13871) or timeouts. 
> I've started this failure in Jenkins (and locally) frequently:
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5410/
> Java: 64bit/jdk-13 -XX:-UseCompressedOops -XX:+UseParallelGC
> 2 tests failed.
> FAILED:  org.apache.solr.cloud.SyncSliceTest.test
> Error Message:
> expected:<5> but was:<4>
> Stack Trace:
> java.lang.AssertionError: expected:<5> but was:<4>
> at 
> __randomizedtesting.SeedInfo.seed([F8E3B768E16E848D:70B788B24F92E975]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at org.apache.solr.cloud.SyncSliceTest.test(SyncSliceTest.java:150)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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.NoShadowingOrOve

[jira] [Commented] (SOLR-13886) HDFSSyncSliceTest and SyncSliceTest started failing frequently

2020-04-18 Thread Kevin Risden (Jira)


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

Kevin Risden commented on SOLR-13886:
-

FYI [~erickerickson] since you were tracking this as part of weekly test 
failures.

> HDFSSyncSliceTest and SyncSliceTest started failing frequently
> --
>
> Key: SOLR-13886
> URL: https://issues.apache.org/jira/browse/SOLR-13886
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-13886.patch
>
>
> While I can see some failures of this test in the past, they weren't frequent 
> and were usually things like port bindings (maybe SOLR-13871) or timeouts. 
> I've started this failure in Jenkins (and locally) frequently:
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5410/
> Java: 64bit/jdk-13 -XX:-UseCompressedOops -XX:+UseParallelGC
> 2 tests failed.
> FAILED:  org.apache.solr.cloud.SyncSliceTest.test
> Error Message:
> expected:<5> but was:<4>
> Stack Trace:
> java.lang.AssertionError: expected:<5> but was:<4>
> at 
> __randomizedtesting.SeedInfo.seed([F8E3B768E16E848D:70B788B24F92E975]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at org.apache.solr.cloud.SyncSliceTest.test(SyncSliceTest.java:150)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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(Test

[jira] [Updated] (SOLR-14414) New Admin UI

2020-04-18 Thread Marcus Eagan (Jira)


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

Marcus Eagan updated SOLR-14414:

Description: 
We have had a lengthy discussion in the mailing list about the need to build a 
modern UI that is both more security and does not depend on deprecated, end of 
life code. In this ticket, I intend to familiarize the community with the 
efforts of the community to do just that that. While we are nearing feature 
parity, but not there yet as many have suggested we could complete this task in 
iterations, here is an attempt to get the ball rolling. I have mostly worked on 
it in weekend nights on the occasion that I could find the time. Angular is 
certainly not my specialty, and this is my first attempt at using TypeScript 
besides a few brief learning exercises here and there. However, I will be 
engaging experts in both of these areas for consultation as our community tries 
to pull our UI into another era.

Many of the components here can improve. One or two them need to be rewritten, 
and there are even at least three essential components to the app missing, 
along with some tests. A couple other things missing are the V2 API,  which I 
found difficult to build with in this context because it is not documented on 
the web. I understand that it is "self-documenting," but the most easy-to-use 
APIs are still documented on the web. Maybe it is entirely documented on the 
web, and I had trouble finding it. Forgive me, as that could be an area of 
assistance. Another area where I need assistance is packaging this application 
as a Solr package. I understand this app is not in the right place for that 
today, but it can be. There are still many improvements to be made in this Jira 
and certainly in this code.

The project is located in {{lucene-solr/solr/webapp2}}, where there is a README 
for information on running the app.

The app can be started from the this directory with {{ng serve}} or {{npm 
start}} for now. One day, it will start on its own.

> New Admin UI
> 
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build 
> a modern UI that is both more security and does not depend on deprecated, end 
> of life code. In this ticket, I intend to familiarize the community with the 
> efforts of the community to do just that that. While we are nearing feature 
> parity, but not there yet as many have suggested we could complete this task 
> in iterations, here is an attempt to get the ball rolling. I have mostly 
> worked on it in weekend nights on the occasion that I could find the time. 
> Angular is certainly not my specialty, and this is my first attempt at using 
> TypeScript besides a few brief learning exercises here and there. However, I 
> will be engaging experts in both of these areas for consultation as our 
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be 
> rewritten, and there are even at least three essential components to the app 
> missing, along with some tests. A couple other things missing are the V2 API, 
>  which I found difficult to build with in this context because it is not 
> documented on the web. I understand that it is "self-documenting," but the 
> most easy-to-use APIs are still documented on the web. Maybe it is entirely 
> documented on the web, and I had trouble finding it. Forgive me, as that 
> could be an area of assistance. Another area where I need assistance is 
> packaging this application as a Solr package. I understand this app is not in 
> the right place for that today, but it can be. There are still many 
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a 
> README for information on running the app.
> The app can be started from the this directory with {{ng serve}} or {{npm 
> start}} for now. One day, it will start on its own.



--
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-14414) New Admin UI - Removes EOL Code

2020-04-18 Thread Marcus Eagan (Jira)


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

Marcus Eagan updated SOLR-14414:

Summary: New Admin UI - Removes EOL Code  (was: New Admin UI)

> New Admin UI - Removes EOL Code
> ---
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build 
> a modern UI that is both more security and does not depend on deprecated, end 
> of life code. In this ticket, I intend to familiarize the community with the 
> efforts of the community to do just that that. While we are nearing feature 
> parity, but not there yet as many have suggested we could complete this task 
> in iterations, here is an attempt to get the ball rolling. I have mostly 
> worked on it in weekend nights on the occasion that I could find the time. 
> Angular is certainly not my specialty, and this is my first attempt at using 
> TypeScript besides a few brief learning exercises here and there. However, I 
> will be engaging experts in both of these areas for consultation as our 
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be 
> rewritten, and there are even at least three essential components to the app 
> missing, along with some tests. A couple other things missing are the V2 API, 
>  which I found difficult to build with in this context because it is not 
> documented on the web. I understand that it is "self-documenting," but the 
> most easy-to-use APIs are still documented on the web. Maybe it is entirely 
> documented on the web, and I had trouble finding it. Forgive me, as that 
> could be an area of assistance. Another area where I need assistance is 
> packaging this application as a Solr package. I understand this app is not in 
> the right place for that today, but it can be. There are still many 
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a 
> README for information on running the app.
> The app can be started from the this directory with {{ng serve}} or {{npm 
> start}} for now. One day, it will start on its own.



--
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-14414) New Admin UI - Removes EOL Code

2020-04-18 Thread Marcus Eagan (Jira)


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

Marcus Eagan updated SOLR-14414:

Description: 
We have had a lengthy discussion in the mailing list about the need to build a 
modern UI that is both more security and does not depend on deprecated, end of 
life code. In this ticket, I intend to familiarize the community with the 
efforts of the community to do just that that. While we are nearing feature 
parity, but not there yet as many have suggested we could complete this task in 
iterations, here is an attempt to get the ball rolling. I have mostly worked on 
it in weekend nights on the occasion that I could find the time. Angular is 
certainly not my specialty, and this is my first attempt at using TypeScript 
besides a few brief learning exercises here and there. However, I will be 
engaging experts in both of these areas for consultation as our community tries 
to pull our UI into another era.

Many of the components here can improve. One or two them need to be rewritten, 
and there are even at least three essential components to the app missing, 
along with some tests. A couple other things missing are the V2 API,  which I 
found difficult to build with in this context because it is not documented on 
the web. I understand that it is "self-documenting," but the most easy-to-use 
APIs are still documented on the web. Maybe it is entirely documented on the 
web, and I had trouble finding it. Forgive me, as that could be an area of 
assistance. Another area where I need assistance is packaging this application 
as a Solr package. I understand this app is not in the right place for that 
today, but it can be. There are still many improvements to be made in this Jira 
and certainly in this code.

The project is located in {{lucene-solr/solr/webapp2}}, where there is a README 
for information on running the app.

The app can be started from the this directory with {{ng serve}} or {{npm 
start}} for now. One day, it will start on its own. I expect there will be a 
lot of opinions. I am prepared. 

  was:
We have had a lengthy discussion in the mailing list about the need to build a 
modern UI that is both more security and does not depend on deprecated, end of 
life code. In this ticket, I intend to familiarize the community with the 
efforts of the community to do just that that. While we are nearing feature 
parity, but not there yet as many have suggested we could complete this task in 
iterations, here is an attempt to get the ball rolling. I have mostly worked on 
it in weekend nights on the occasion that I could find the time. Angular is 
certainly not my specialty, and this is my first attempt at using TypeScript 
besides a few brief learning exercises here and there. However, I will be 
engaging experts in both of these areas for consultation as our community tries 
to pull our UI into another era.

Many of the components here can improve. One or two them need to be rewritten, 
and there are even at least three essential components to the app missing, 
along with some tests. A couple other things missing are the V2 API,  which I 
found difficult to build with in this context because it is not documented on 
the web. I understand that it is "self-documenting," but the most easy-to-use 
APIs are still documented on the web. Maybe it is entirely documented on the 
web, and I had trouble finding it. Forgive me, as that could be an area of 
assistance. Another area where I need assistance is packaging this application 
as a Solr package. I understand this app is not in the right place for that 
today, but it can be. There are still many improvements to be made in this Jira 
and certainly in this code.

The project is located in {{lucene-solr/solr/webapp2}}, where there is a README 
for information on running the app.

The app can be started from the this directory with {{ng serve}} or {{npm 
start}} for now. One day, it will start on its own.


> New Admin UI - Removes EOL Code
> ---
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build 
> a modern UI that is both more security and does not depend on deprecated, end 
> of life code. In this ticket, I intend to familiarize the community with the 
> efforts of the community to do just that that. While we are nearing feature 
> parity, but not there yet as many have suggested we could complete this task 
> in iterations, here is an attempt to get the ball rolling. I have mostly 
> worked on it in weekend nights on t

[jira] [Commented] (SOLR-13886) HDFSSyncSliceTest and SyncSliceTest started failing frequently

2020-04-18 Thread Kevin Risden (Jira)


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

Kevin Risden commented on SOLR-13886:
-

The patch attached fixes the issue with the following seed that was reproducing:

{code:java}
ant test  -Dtestcase=HdfsSyncSliceTest -Dtests.method=test 
-Dtests.seed=8D96066C658EE14 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.locale=en-TK -Dtests.timezone=Pacific/Fakaofo -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
{code}

I've also checked that this beasts with both Hdfs and the regular SyncSlideTest.

{code:java}
ant beast -Dtestcase='*SyncSliceTest' -Dtests.method=test -Dtests.nightly=true 
-Dtests.slow=true -Dtests.asserts=true -Dtests.locale=en-TK -Dbeast.iters=20
{code}

^^^ The locale in the above is to ensure that the HDFS test isn't skipped due 
to some invalid locales. This causes beast to fail when no valid test is found. 
I have checked w/ different locales and the patch still works.


> HDFSSyncSliceTest and SyncSliceTest started failing frequently
> --
>
> Key: SOLR-13886
> URL: https://issues.apache.org/jira/browse/SOLR-13886
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-13886.patch
>
>
> While I can see some failures of this test in the past, they weren't frequent 
> and were usually things like port bindings (maybe SOLR-13871) or timeouts. 
> I've started this failure in Jenkins (and locally) frequently:
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5410/
> Java: 64bit/jdk-13 -XX:-UseCompressedOops -XX:+UseParallelGC
> 2 tests failed.
> FAILED:  org.apache.solr.cloud.SyncSliceTest.test
> Error Message:
> expected:<5> but was:<4>
> Stack Trace:
> java.lang.AssertionError: expected:<5> but was:<4>
> at 
> __randomizedtesting.SeedInfo.seed([F8E3B768E16E848D:70B788B24F92E975]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at org.apache.solr.cloud.SyncSliceTest.test(SyncSliceTest.java:150)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
>   

[jira] [Updated] (SOLR-13886) HDFSSyncSliceTest and SyncSliceTest started failing frequently

2020-04-18 Thread Kevin Risden (Jira)


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

Kevin Risden updated SOLR-13886:

Attachment: SOLR-13886_jenkins_log.txt.gz

> HDFSSyncSliceTest and SyncSliceTest started failing frequently
> --
>
> Key: SOLR-13886
> URL: https://issues.apache.org/jira/browse/SOLR-13886
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-13886.patch, SOLR-13886_jenkins_log.txt.gz
>
>
> While I can see some failures of this test in the past, they weren't frequent 
> and were usually things like port bindings (maybe SOLR-13871) or timeouts. 
> I've started this failure in Jenkins (and locally) frequently:
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5410/
> Java: 64bit/jdk-13 -XX:-UseCompressedOops -XX:+UseParallelGC
> 2 tests failed.
> FAILED:  org.apache.solr.cloud.SyncSliceTest.test
> Error Message:
> expected:<5> but was:<4>
> Stack Trace:
> java.lang.AssertionError: expected:<5> but was:<4>
> at 
> __randomizedtesting.SeedInfo.seed([F8E3B768E16E848D:70B788B24F92E975]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at org.apache.solr.cloud.SyncSliceTest.test(SyncSliceTest.java:150)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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.rand

[jira] [Updated] (SOLR-14414) New Admin UI - Removes EOL Code

2020-04-18 Thread Marcus Eagan (Jira)


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

Marcus Eagan updated SOLR-14414:

Description: 
We have had a lengthy discussion in the mailing list about the need to build a 
modern UI that is both more security and does not depend on deprecated, end of 
life code. In this ticket, I intend to familiarize the community with the 
efforts of the community to do just that that. While we are nearing feature 
parity, but not there yet as many have suggested we could complete this task in 
iterations, here is an attempt to get the ball rolling. I have mostly worked on 
it in weekend nights on the occasion that I could find the time. Angular is 
certainly not my specialty, and this is my first attempt at using TypeScript 
besides a few brief learning exercises here and there. However, I will be 
engaging experts in both of these areas for consultation as our community tries 
to pull our UI into another era.

Many of the components here can improve. One or two them need to be rewritten, 
and there are even at least three essential components to the app missing, 
along with some tests. A couple other things missing are the V2 API,  which I 
found difficult to build with in this context because it is not documented on 
the web. I understand that it is "self-documenting," but the most easy-to-use 
APIs are still documented on the web. Maybe it is entirely documented on the 
web, and I had trouble finding it. Forgive me, as that could be an area of 
assistance. Another area where I need assistance is packaging this application 
as a Solr package. I understand this app is not in the right place for that 
today, but it can be. There are still many improvements to be made in this Jira 
and certainly in this code.

The project is located in {{lucene-solr/solr/webapp2}}, where there is a README 
for information on running the app.

The app can be started from the this directory with {{npm start}} for now. One 
day, it will start on its own. I expect there will be a lot of opinions. I am 
prepared. 

  was:
We have had a lengthy discussion in the mailing list about the need to build a 
modern UI that is both more security and does not depend on deprecated, end of 
life code. In this ticket, I intend to familiarize the community with the 
efforts of the community to do just that that. While we are nearing feature 
parity, but not there yet as many have suggested we could complete this task in 
iterations, here is an attempt to get the ball rolling. I have mostly worked on 
it in weekend nights on the occasion that I could find the time. Angular is 
certainly not my specialty, and this is my first attempt at using TypeScript 
besides a few brief learning exercises here and there. However, I will be 
engaging experts in both of these areas for consultation as our community tries 
to pull our UI into another era.

Many of the components here can improve. One or two them need to be rewritten, 
and there are even at least three essential components to the app missing, 
along with some tests. A couple other things missing are the V2 API,  which I 
found difficult to build with in this context because it is not documented on 
the web. I understand that it is "self-documenting," but the most easy-to-use 
APIs are still documented on the web. Maybe it is entirely documented on the 
web, and I had trouble finding it. Forgive me, as that could be an area of 
assistance. Another area where I need assistance is packaging this application 
as a Solr package. I understand this app is not in the right place for that 
today, but it can be. There are still many improvements to be made in this Jira 
and certainly in this code.

The project is located in {{lucene-solr/solr/webapp2}}, where there is a README 
for information on running the app.

The app can be started from the this directory with {{ng serve}} or {{npm 
start}} for now. One day, it will start on its own. I expect there will be a 
lot of opinions. I am prepared. 


> New Admin UI - Removes EOL Code
> ---
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build 
> a modern UI that is both more security and does not depend on deprecated, end 
> of life code. In this ticket, I intend to familiarize the community with the 
> efforts of the community to do just that that. While we are nearing feature 
> parity, but not there yet as many have suggested we could complete this task 
> in iterations, here is an attempt to get the ball rolling. I have mo

[GitHub] [lucene-solr] MarcusSorealheis opened a new pull request #1438: Admin UI refresh. Still many things to fix, but a big improvement fro…

2020-04-18 Thread GitBox
MarcusSorealheis opened a new pull request #1438: Admin UI refresh. Still many 
things to fix, but a big improvement fro…
URL: https://github.com/apache/lucene-solr/pull/1438
 
 
   …m safety. Still stuck in the call stack searching for memory leaks and 
debugging control flow issues.
   
   
   
   
   # Description
   
   The current admin UI, while very useful, is dangerous. Upgrading the Admin 
UI to use non-EOL code. This app uses the latest version of Angular. 
   
   # Solution
   
   Uses the Angular CLI and the dashboard work from a guy with a great design 
eye. Also in TypeScript.
   
   # Tests
   
   There's a lot of tests here, integration tests, and manual integration 
tests. There is still some inconsistency here, but working to improve it over 
the next couple months.
   
   # 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


With regards,
Apache Git Services

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



[jira] [Commented] (SOLR-14414) New Admin UI - Removes EOL Code

2020-04-18 Thread Marcus Eagan (Jira)


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

Marcus Eagan commented on SOLR-14414:
-

Does anyone know a quick way to add Apache license header to every file. I can 
do it but was curious if someone else out there wrote some PERL to do this or 
loves adding license files.

> New Admin UI - Removes EOL Code
> ---
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build 
> a modern UI that is both more security and does not depend on deprecated, end 
> of life code. In this ticket, I intend to familiarize the community with the 
> efforts of the community to do just that that. While we are nearing feature 
> parity, but not there yet as many have suggested we could complete this task 
> in iterations, here is an attempt to get the ball rolling. I have mostly 
> worked on it in weekend nights on the occasion that I could find the time. 
> Angular is certainly not my specialty, and this is my first attempt at using 
> TypeScript besides a few brief learning exercises here and there. However, I 
> will be engaging experts in both of these areas for consultation as our 
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be 
> rewritten, and there are even at least three essential components to the app 
> missing, along with some tests. A couple other things missing are the V2 API, 
>  which I found difficult to build with in this context because it is not 
> documented on the web. I understand that it is "self-documenting," but the 
> most easy-to-use APIs are still documented on the web. Maybe it is entirely 
> documented on the web, and I had trouble finding it. Forgive me, as that 
> could be an area of assistance. Another area where I need assistance is 
> packaging this application as a Solr package. I understand this app is not in 
> the right place for that today, but it can be. There are still many 
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a 
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. 
> One day, it will start on its own. I expect there will be a lot of opinions. 
> I am prepared. 



--
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-14414) New Admin UI - Removes EOL Code

2020-04-18 Thread Marcus Eagan (Jira)


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

Marcus Eagan edited comment on SOLR-14414 at 4/18/20, 6:23 PM:
---

Does anyone know a quick way to add Apache license header to every file. I can 
do it but was curious if someone else out there wrote some PERL to do this or 
loves adding license files.

https://github.com/apache/lucene-solr/pull/1438


was (Author: marcussorealheis):
Does anyone know a quick way to add Apache license header to every file. I can 
do it but was curious if someone else out there wrote some PERL to do this or 
loves adding license files.

> New Admin UI - Removes EOL Code
> ---
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build 
> a modern UI that is both more security and does not depend on deprecated, end 
> of life code. In this ticket, I intend to familiarize the community with the 
> efforts of the community to do just that that. While we are nearing feature 
> parity, but not there yet as many have suggested we could complete this task 
> in iterations, here is an attempt to get the ball rolling. I have mostly 
> worked on it in weekend nights on the occasion that I could find the time. 
> Angular is certainly not my specialty, and this is my first attempt at using 
> TypeScript besides a few brief learning exercises here and there. However, I 
> will be engaging experts in both of these areas for consultation as our 
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be 
> rewritten, and there are even at least three essential components to the app 
> missing, along with some tests. A couple other things missing are the V2 API, 
>  which I found difficult to build with in this context because it is not 
> documented on the web. I understand that it is "self-documenting," but the 
> most easy-to-use APIs are still documented on the web. Maybe it is entirely 
> documented on the web, and I had trouble finding it. Forgive me, as that 
> could be an area of assistance. Another area where I need assistance is 
> packaging this application as a Solr package. I understand this app is not in 
> the right place for that today, but it can be. There are still many 
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a 
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. 
> One day, it will start on its own. I expect there will be a lot of opinions. 
> I am prepared. 



--
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-14414) New Admin UI

2020-04-18 Thread Marcus Eagan (Jira)


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

Marcus Eagan updated SOLR-14414:

Summary: New Admin UI  (was: New Admin UI - Removes EOL Code)

> New Admin UI
> 
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build 
> a modern UI that is both more security and does not depend on deprecated, end 
> of life code. In this ticket, I intend to familiarize the community with the 
> efforts of the community to do just that that. While we are nearing feature 
> parity, but not there yet as many have suggested we could complete this task 
> in iterations, here is an attempt to get the ball rolling. I have mostly 
> worked on it in weekend nights on the occasion that I could find the time. 
> Angular is certainly not my specialty, and this is my first attempt at using 
> TypeScript besides a few brief learning exercises here and there. However, I 
> will be engaging experts in both of these areas for consultation as our 
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be 
> rewritten, and there are even at least three essential components to the app 
> missing, along with some tests. A couple other things missing are the V2 API, 
>  which I found difficult to build with in this context because it is not 
> documented on the web. I understand that it is "self-documenting," but the 
> most easy-to-use APIs are still documented on the web. Maybe it is entirely 
> documented on the web, and I had trouble finding it. Forgive me, as that 
> could be an area of assistance. Another area where I need assistance is 
> packaging this application as a Solr package. I understand this app is not in 
> the right place for that today, but it can be. There are still many 
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a 
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. 
> One day, it will start on its own. I expect there will be a lot of opinions. 
> I am prepared. 



--
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] MarcusSorealheis commented on issue #1391: SOLR-14014 Add a disable Admin UI Flag

2020-04-18 Thread GitBox
MarcusSorealheis commented on issue #1391: SOLR-14014 Add a disable Admin UI 
Flag
URL: https://github.com/apache/lucene-solr/pull/1391#issuecomment-615943497
 
 
   @gerlowskija soft knock 


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


With regards,
Apache Git Services

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



[jira] [Updated] (LUCENE-9328) SortingGroupHead to reuse DocValues

2020-04-18 Thread Mikhail Khludnev (Jira)


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

Mikhail Khludnev updated LUCENE-9328:
-
Attachment: LUCENE-9328.patch
Status: Open  (was: Open)

> SortingGroupHead to reuse DocValues
> ---
>
> Key: LUCENE-9328
> URL: https://issues.apache.org/jira/browse/LUCENE-9328
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: LUCENE-9328.patch
>
>
> That's why 
> https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365



--
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-9328) SortingGroupHead to reuse DocValues

2020-04-18 Thread Alan Woodward (Jira)


[ 
https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17086679#comment-17086679
 ] 

Alan Woodward commented on LUCENE-9328:
---

Can we try and avoid making any changes to FieldComparator and friends?  I 
think we can do this entirely within AllGroupHeadsCollector, by wrapping 
incoming LeafReaders with a FilterLeafReader that caches the various DocValues 
iterators.  We may need to make some changes to allow a FilterLeafReader to 
keep its inner reader's context though, so that the comparators see the correct 
docBase.

> SortingGroupHead to reuse DocValues
> ---
>
> Key: LUCENE-9328
> URL: https://issues.apache.org/jira/browse/LUCENE-9328
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/grouping
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: LUCENE-9328.patch
>
>
> That's why 
> https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365



--
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-7788) fail precommit on unparameterised log messages and examine for wasted work/objects

2020-04-18 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/LUCENE-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17086682#comment-17086682
 ] 

ASF subversion and git services commented on LUCENE-7788:
-

Commit 1f1cdbffdf607db961049d1417b18dc6cbf53d7a in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1f1cdbf ]

LUCENE-7788: fail precommit on unparameterised log messages and examine for 
wasted work/objects


> fail precommit on unparameterised log messages and examine for wasted 
> work/objects
> --
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-7788.patch, LUCENE-7788.patch, gradle_only.patch, 
> gradle_only.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use 
> and once that is in place then this ticket's one-line change would be for 
> 'ant precommit' to reject any future unparameterised log.trace message use.



--
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-7788) fail precommit on unparameterised log messages and examine for wasted work/objects

2020-04-18 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/LUCENE-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17086683#comment-17086683
 ] 

ASF subversion and git services commented on LUCENE-7788:
-

Commit 99555b91350f9c09defb8b5326803f63bb71e13d in lucene-solr's branch 
refs/heads/branch_8x from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=99555b9 ]

LUCENE-7788: fail precommit on unparameterised log messages and examine for 
wasted work/objects


> fail precommit on unparameterised log messages and examine for wasted 
> work/objects
> --
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-7788.patch, LUCENE-7788.patch, gradle_only.patch, 
> gradle_only.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use 
> and once that is in place then this ticket's one-line change would be for 
> 'ant precommit' to reject any future unparameterised log.trace message use.



--
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] dsmiley closed pull request #1409: SOLR-14391: getDocSet(Query[]) can use search(query, collector)

2020-04-18 Thread GitBox
dsmiley closed pull request #1409: SOLR-14391: getDocSet(Query[]) can use 
search(query,collector)
URL: https://github.com/apache/lucene-solr/pull/1409
 
 
   


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


With regards,
Apache Git Services

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



[jira] [Commented] (SOLR-14391) Remove getDocSet's manual doc collection logic; remove ScoreFilter

2020-04-18 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on SOLR-14391:


Commit f5d91395db217b03fcec5e1799c0c77ebbdc8ca6 in lucene-solr's branch 
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f5d9139 ]

SOLR-14391: getDocSet(Query[]) can use search(query,collector)
Refactoring to simplify SolrIndexSearcher.
ScoreFilter interface is obsolete now.
Fixed #1409


> Remove getDocSet's manual doc collection logic; remove ScoreFilter
> --
>
> Key: SOLR-14391
> URL: https://issues.apache.org/jira/browse/SOLR-14391
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{SolrIndexSearcher.getDocSet(List)}} calls getProcessedFilter and 
> then basically loops over doc IDs, passing them through the filter, and 
> passes them to the Collector.  This logic is redundant with what Lucene 
> searcher.search(query,collector) will ultimately do in BulkScorer, and so I 
> propose we remove all that code and delegate to Lucene.
> Also, the top of this method looks to see if any query implements the 
> "ScoreFilter" marker interface (only implemented by CollapsingPostFilter) and 
> if so delegates to {{getDocSetScore}} method instead.  That method has an 
> implementation close to what I propose getDocSet be changed to; so it can be 
> removed along with this ScoreFilter interface 
> searcher.search(query,collector).



--
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-14391) Remove getDocSet's manual doc collection logic; remove ScoreFilter

2020-04-18 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on SOLR-14391:


Commit 1c11962076e0dbdb90511219544aefdcdc7536c1 in lucene-solr's branch 
refs/heads/branch_8x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1c11962 ]

SOLR-14391: getDocSet(Query[]) can use search(query,collector)
Refactoring to simplify SolrIndexSearcher.
ScoreFilter interface is obsolete now.
Fixed #1409

(cherry picked from commit f5d91395db217b03fcec5e1799c0c77ebbdc8ca6)


> Remove getDocSet's manual doc collection logic; remove ScoreFilter
> --
>
> Key: SOLR-14391
> URL: https://issues.apache.org/jira/browse/SOLR-14391
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{SolrIndexSearcher.getDocSet(List)}} calls getProcessedFilter and 
> then basically loops over doc IDs, passing them through the filter, and 
> passes them to the Collector.  This logic is redundant with what Lucene 
> searcher.search(query,collector) will ultimately do in BulkScorer, and so I 
> propose we remove all that code and delegate to Lucene.
> Also, the top of this method looks to see if any query implements the 
> "ScoreFilter" marker interface (only implemented by CollapsingPostFilter) and 
> if so delegates to {{getDocSetScore}} method instead.  That method has an 
> implementation close to what I propose getDocSet be changed to; so it can be 
> removed along with this ScoreFilter interface 
> searcher.search(query,collector).



--
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-13886) HDFSSyncSliceTest and SyncSliceTest started failing frequently

2020-04-18 Thread Erick Erickson (Jira)


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

Erick Erickson commented on SOLR-13886:
---

[~krisden] I'm not doing anything special to track failures, just collating 
Hoss' reports each week from here:

http://fucit.org/solr-jenkins-reports/

Go to the "past 24h / 7 days" section and you can pick a test. From there, I 
look over the last 4 weeks for my weekly report. Well, I wrote a program ;).

So by all means go ahead and push it. I'd be happy to beast it overnight, apply 
the patch tomorrow and try again...







> HDFSSyncSliceTest and SyncSliceTest started failing frequently
> --
>
> Key: SOLR-13886
> URL: https://issues.apache.org/jira/browse/SOLR-13886
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-13886.patch, SOLR-13886_jenkins_log.txt.gz
>
>
> While I can see some failures of this test in the past, they weren't frequent 
> and were usually things like port bindings (maybe SOLR-13871) or timeouts. 
> I've started this failure in Jenkins (and locally) frequently:
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5410/
> Java: 64bit/jdk-13 -XX:-UseCompressedOops -XX:+UseParallelGC
> 2 tests failed.
> FAILED:  org.apache.solr.cloud.SyncSliceTest.test
> Error Message:
> expected:<5> but was:<4>
> Stack Trace:
> java.lang.AssertionError: expected:<5> but was:<4>
> at 
> __randomizedtesting.SeedInfo.seed([F8E3B768E16E848D:70B788B24F92E975]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at org.apache.solr.cloud.SyncSliceTest.test(SyncSliceTest.java:150)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> 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:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomized

[jira] [Resolved] (SOLR-14391) Remove getDocSet's manual doc collection logic; remove ScoreFilter

2020-04-18 Thread David Smiley (Jira)


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

David Smiley resolved SOLR-14391.
-
Fix Version/s: 8.6
   Resolution: Fixed

> Remove getDocSet's manual doc collection logic; remove ScoreFilter
> --
>
> Key: SOLR-14391
> URL: https://issues.apache.org/jira/browse/SOLR-14391
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{SolrIndexSearcher.getDocSet(List)}} calls getProcessedFilter and 
> then basically loops over doc IDs, passing them through the filter, and 
> passes them to the Collector.  This logic is redundant with what Lucene 
> searcher.search(query,collector) will ultimately do in BulkScorer, and so I 
> propose we remove all that code and delegate to Lucene.
> Also, the top of this method looks to see if any query implements the 
> "ScoreFilter" marker interface (only implemented by CollapsingPostFilter) and 
> if so delegates to {{getDocSetScore}} method instead.  That method has an 
> implementation close to what I propose getDocSet be changed to; so it can be 
> removed along with this ScoreFilter interface 
> searcher.search(query,collector).



--
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-14414) New Admin UI

2020-04-18 Thread Marcus Eagan (Jira)


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

Marcus Eagan updated SOLR-14414:

Description: 
We have had a lengthy discussion in the mailing list about the need to build a 
modern UI that is both more security and does not depend on deprecated, end of 
life code. In this ticket, I intend to familiarize the community with the 
efforts of the community to do just that that. While we are nearing feature 
parity, but not there yet as many have suggested we could complete this task in 
iterations, here is an attempt to get the ball rolling. I have mostly worked on 
it in weekend nights on the occasion that I could find the time. Angular is 
certainly not my specialty, and this is my first attempt at using TypeScript 
besides a few brief learning exercises here and there. However, I will be 
engaging experts in both of these areas for consultation as our community tries 
to pull our UI into another era.

Many of the components here can improve. One or two them need to be rewritten, 
and there are even at least three essential components to the app missing, 
along with some tests. A couple other things missing are the V2 API,  which I 
found difficult to build with in this context because it is not documented on 
the web. I understand that it is "self-documenting," but the most easy-to-use 
APIs are still documented on the web. Maybe it is entirely documented on the 
web, and I had trouble finding it. Forgive me, as that could be an area of 
assistance. Another area where I need assistance is packaging this application 
as a Solr package. I understand this app is not in the right place for that 
today, but it can be. There are still many improvements to be made in this Jira 
and certainly in this code.

The project is located in {{lucene-solr/solr/webapp2}}, where there is a README 
for information on running the app.

The app can be started from the this directory with {{npm start}} for now. One 
day, it will start as a part of the typical start commands. I expect there will 
be a lot of opinions. I welcome them, of course. The community input should 
drive the project's success. 

  was:
We have had a lengthy discussion in the mailing list about the need to build a 
modern UI that is both more security and does not depend on deprecated, end of 
life code. In this ticket, I intend to familiarize the community with the 
efforts of the community to do just that that. While we are nearing feature 
parity, but not there yet as many have suggested we could complete this task in 
iterations, here is an attempt to get the ball rolling. I have mostly worked on 
it in weekend nights on the occasion that I could find the time. Angular is 
certainly not my specialty, and this is my first attempt at using TypeScript 
besides a few brief learning exercises here and there. However, I will be 
engaging experts in both of these areas for consultation as our community tries 
to pull our UI into another era.

Many of the components here can improve. One or two them need to be rewritten, 
and there are even at least three essential components to the app missing, 
along with some tests. A couple other things missing are the V2 API,  which I 
found difficult to build with in this context because it is not documented on 
the web. I understand that it is "self-documenting," but the most easy-to-use 
APIs are still documented on the web. Maybe it is entirely documented on the 
web, and I had trouble finding it. Forgive me, as that could be an area of 
assistance. Another area where I need assistance is packaging this application 
as a Solr package. I understand this app is not in the right place for that 
today, but it can be. There are still many improvements to be made in this Jira 
and certainly in this code.

The project is located in {{lucene-solr/solr/webapp2}}, where there is a README 
for information on running the app.

The app can be started from the this directory with {{npm start}} for now. One 
day, it will start on its own. I expect there will be a lot of opinions. I am 
prepared. 


> New Admin UI
> 
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build 
> a modern UI that is both more security and does not depend on deprecated, end 
> of life code. In this ticket, I intend to familiarize the community with the 
> efforts of the community to do just that that. While we are nearing feature 
> parity, but not there yet as many have suggested we could complete this task 
> in iterations, here is a

[jira] [Commented] (SOLR-14391) Remove getDocSet's manual doc collection logic; remove ScoreFilter

2020-04-18 Thread Shalin Shekhar Mangar (Jira)


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

Shalin Shekhar Mangar commented on SOLR-14391:
--

bq. Given that this dates back to Lucene 3.2 or so, it was probably the most 
performant way, regardless if there was another way or not.

Is this still the most performant way? [~dsmiley] -- did you compare 
performance before removing the manual doc loop?

> Remove getDocSet's manual doc collection logic; remove ScoreFilter
> --
>
> Key: SOLR-14391
> URL: https://issues.apache.org/jira/browse/SOLR-14391
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{SolrIndexSearcher.getDocSet(List)}} calls getProcessedFilter and 
> then basically loops over doc IDs, passing them through the filter, and 
> passes them to the Collector.  This logic is redundant with what Lucene 
> searcher.search(query,collector) will ultimately do in BulkScorer, and so I 
> propose we remove all that code and delegate to Lucene.
> Also, the top of this method looks to see if any query implements the 
> "ScoreFilter" marker interface (only implemented by CollapsingPostFilter) and 
> if so delegates to {{getDocSetScore}} method instead.  That method has an 
> implementation close to what I propose getDocSet be changed to; so it can be 
> removed along with this ScoreFilter interface 
> searcher.search(query,collector).



--
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-14391) Remove getDocSet's manual doc collection logic; remove ScoreFilter

2020-04-18 Thread David Smiley (Jira)


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

David Smiley commented on SOLR-14391:
-

I confess I did not Shalin.  My objective is to remove obstacles that unlock 
TwoPhaseIterator for non-cached filters -- SOLR-14166 (which I am updating just 
now).  _That_ is a performance optimization that this older code relying on the 
old Filter was in the way of.  [~gerlowskija] I recall you had some nice 
performance test of some non-cached filters.  Is it something you could show me 
(point me at the code) that I could try?

> Remove getDocSet's manual doc collection logic; remove ScoreFilter
> --
>
> Key: SOLR-14391
> URL: https://issues.apache.org/jira/browse/SOLR-14391
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{SolrIndexSearcher.getDocSet(List)}} calls getProcessedFilter and 
> then basically loops over doc IDs, passing them through the filter, and 
> passes them to the Collector.  This logic is redundant with what Lucene 
> searcher.search(query,collector) will ultimately do in BulkScorer, and so I 
> propose we remove all that code and delegate to Lucene.
> Also, the top of this method looks to see if any query implements the 
> "ScoreFilter" marker interface (only implemented by CollapsingPostFilter) and 
> if so delegates to {{getDocSetScore}} method instead.  That method has an 
> implementation close to what I propose getDocSet be changed to; so it can be 
> removed along with this ScoreFilter interface 
> searcher.search(query,collector).



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