[GitHub] [lucene-solr] uschindler commented on a change in pull request #1837: LUCENE-7882: First idea of using Java 15 hidden anonymous classes for Lucene expressions

[GitBox]

uschindler commented on a change in pull request #1837:
URL: https://github.com/apache/lucene-solr/pull/1837#discussion_r484222322



##
File path: 
lucene/expressions/src/test/org/apache/lucene/expressions/js/TestCustomFunctions.java
##
@@ -263,7 +263,7 @@ public void testThrowingException() throws Exception {
 PrintWriter pw = new PrintWriter(sw);

Review comment:
   Yeah, I added this only for my personal debugging, because this test 
fails with my change (as the expression is hidden from the stack trace, so the 
"contains" does not work. But when it fails, you don't see what should be there.
   
   Assertj is really better as it automatically prints and also shortens the 
printout to only relevant part.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler commented on a change in pull request #1837: LUCENE-7882: First idea of using Java 15 hidden anonymous classes for Lucene expressions

[GitBox]

uschindler commented on a change in pull request #1837:
URL: https://github.com/apache/lucene-solr/pull/1837#discussion_r484223373



##
File path: 
lucene/expressions/src/java/org/apache/lucene/expressions/js/JavascriptCompiler.java
##
@@ -206,6 +247,12 @@ private Expression compileExpression(ClassLoader parent) 
throws ParseException {
   throw new IllegalStateException("An internal error occurred attempting 
to compile the expression (" + sourceText + ").", exception);
 }
   }
+  

Review comment:
   I changed it. The way how to do this is correct as it only intends to 
work around a problem of type inference in javac. For a methodhandle we know 
for sure, which exceptions are thrown (it's different to core reflection, where 
everything is wrapped in InvocationTargetException).
   
   I moved the whole thing to a separate method and I catched and rethrow all 
"known" Exceptions (IllegalAccessException, RuntimeException, Error), all 
others can't happen, so it wraps with AssertionError.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] dweiss commented on a change in pull request #1837: LUCENE-7882: First idea of using Java 15 hidden anonymous classes for Lucene expressions

[GitBox]

dweiss commented on a change in pull request #1837:
URL: https://github.com/apache/lucene-solr/pull/1837#discussion_r484223431



##
File path: 
lucene/expressions/src/test/org/apache/lucene/expressions/js/TestCustomFunctions.java
##
@@ -263,7 +263,7 @@ public void testThrowingException() throws Exception {
 PrintWriter pw = new PrintWriter(sw);

Review comment:
   I love assertj - it really prints out stuff in more elegant fashion than 
pure junit+hamcrest.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler commented on a change in pull request #1837: LUCENE-7882: First idea of using Java 15 hidden anonymous classes for Lucene expressions

[GitBox]

uschindler commented on a change in pull request #1837:
URL: https://github.com/apache/lucene-solr/pull/1837#discussion_r484229443



##
File path: 
lucene/expressions/src/java/org/apache/lucene/expressions/js/JavascriptCompiler.java
##
@@ -191,9 +220,21 @@ private Expression compileExpression(ClassLoader parent) 
throws ParseException {
 
 try {
   generateClass(getAntlrParseTree(), classWriter, externalsMap);
-
-  final Class evaluatorClass = new Loader(parent)
-.define(COMPILED_EXPRESSION_CLASS, classWriter.toByteArray());
+  
+  final Class evaluatorClass;

Review comment:
   I was thinking about that, but as it throws a checked Exception it would 
need a new functional interface. I moved the whole stuff to a separate method 
`defineClass()`.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Commented] (LUCENE-9504) DocumentsWriterDeleteQueue.forceApplyGlobalSlice has needless locking

[Simon Willnauer (Jira)]

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

Simon Willnauer commented on LUCENE-9504:
-

there is no need for measuring impact. This is a leftover I think. It's only 
used in tests anyway.

> DocumentsWriterDeleteQueue.forceApplyGlobalSlice has needless locking
> -
>
> Key: LUCENE-9504
> URL: https://issues.apache.org/jira/browse/LUCENE-9504
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{DocumentsWriterDeleteQueue.forceApplyGlobalSlice}} is only called from 
> {{getBufferedUpdateTermsSize}} so we end up doing double the locking. It's 
> not a huge problem because re-entrant locks are cheap, but we can probably 
> unwrap the methods a little bit here.
> This may impact HotSpot inlining, I haven't tried measuring that yet. If that 
> is a concern, please let me know.



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

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

[GitHub] [lucene-solr] uschindler commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688194137


   Hi, I am reviewing: Actually the whole task does not scan any files, as the 
"extensions" are wrongly expanded. Should be `**/*.${it}`. I will commit a fix 
together with many other changes.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler edited a comment on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler edited a comment on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688194137


   Hi, I am reviewing: Actually the whole task does not scan any files, as the 
"extensions" are wrongly expanded. Should be `**/*.${it}`. I will commit a fix 
together with many other changes. This is why many errors by wrong excludes 
were not reported.
   
   Actually the task is now not much faster than before!



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688199213


   Actually for me the splitted tasks take much longer to complete: almost 
30 seconds. Maybe it's caused by the progress meter.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688200016


   The other problem is that for ":solr" and ":lucene" it scans files twice, as 
the fileTree includes again the subprojects!



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] dweiss commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

dweiss commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688201937


   bq. Actually the whole task does not scan any files
   
   Ah, so this would explain the speedup. :)
   
   Let me reiterate, sorry about the noise.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688203183


   I committed my changes. You see the duplicate scanning now, because it 
reports hadoop errors in `:solr`, becaus ethe exclude does not work correctly. 
In fact `:solr` should not scan its subdirectories.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler edited a comment on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler edited a comment on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688203183


   I committed my changes. You see the duplicate scanning now, because it 
reports hadoop errors in `:solr`, because the exclude does not work correctly. 
In fact `:solr` should not scan its subdirectories.
   
   Not sure how to handle this easily. I tend to give up on this approach, 
maybe only split lucene and solr.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] dweiss commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

dweiss commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688210409


   I'll take a look, but not now - working.
   
   On Mon, Sep 7, 2020 at 11:38 AM Uwe Schindler 
   wrote:
   
   > I committed my changes. You see the duplicate scanning now, because it
   > reports hadoop errors in :solr, becaus ethe exclude does not work
   > correctly. In fact :solr should not scan its subdirectories.
   >
   > —
   > You are receiving this because you authored the thread.
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   >
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Commented] (LUCENE-9509) Refine lucene/BUILD.md (move Solr related contents to top-level README)

[ASF subversion and git services (Jira)]

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

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

Commit 51484e138bfa0b96dac5456828c8d74f5b18944d in lucene-solr's branch 
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=51484e1 ]

LUCENE-9509: Refine lucene/BUILD.md and top-level README (for newdevs) (#1835)



> Refine lucene/BUILD.md (move Solr related contents to top-level README)
> ---
>
> Key: LUCENE-9509
> URL: https://issues.apache.org/jira/browse/LUCENE-9509
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Current lucene/BUILD.md is somehow mixed-up with information for Solr 
> developers, this is wrong place for them. Solr related information/tips 
> should be moved to the top-level README (or somewhere else).
> Also the content could be elaborated for newdevs.



--
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] mocobeta merged pull request #1835: LUCENE-9509: Refine lucene/BUILD.md and top-level README (for newdevs)

[GitBox]

mocobeta merged pull request #1835:
URL: https://github.com/apache/lucene-solr/pull/1835


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Resolved] (LUCENE-9509) Refine lucene/BUILD.md (move Solr related contents to top-level README)

[Tomoko Uchida (Jira)]

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

Tomoko Uchida resolved LUCENE-9509.
---
Resolution: Fixed

> Refine lucene/BUILD.md (move Solr related contents to top-level README)
> ---
>
> Key: LUCENE-9509
> URL: https://issues.apache.org/jira/browse/LUCENE-9509
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Current lucene/BUILD.md is somehow mixed-up with information for Solr 
> developers, this is wrong place for them. Solr related information/tips 
> should be moved to the top-level README (or somewhere else).
> Also the content could be elaborated for newdevs.



--
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-9509) Refine lucene/BUILD.md (move Solr related contents to top-level README)

[Tomoko Uchida (Jira)]

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

Tomoko Uchida commented on LUCENE-9509:
---

Thanks Erick for reviewing. I also think it would be nice to move Solr specific 
information (build etc.) from top-level README to solr/README.md (or we could 
have solr/BUILD.me for developers ?).

> Refine lucene/BUILD.md (move Solr related contents to top-level README)
> ---
>
> Key: LUCENE-9509
> URL: https://issues.apache.org/jira/browse/LUCENE-9509
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Current lucene/BUILD.md is somehow mixed-up with information for Solr 
> developers, this is wrong place for them. Solr related information/tips 
> should be moved to the top-level README (or somewhere else).
> Also the content could be elaborated for newdevs.



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

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

[jira] [Updated] (LUCENE-9509) Refine lucene/BUILD.md (move Solr related contents to top-level README)

[Tomoko Uchida (Jira)]

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

Tomoko Uchida updated LUCENE-9509:
--
Fix Version/s: master (9.0)

> Refine lucene/BUILD.md (move Solr related contents to top-level README)
> ---
>
> Key: LUCENE-9509
> URL: https://issues.apache.org/jira/browse/LUCENE-9509
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0)
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Current lucene/BUILD.md is somehow mixed-up with information for Solr 
> developers, this is wrong place for them. Solr related information/tips 
> should be moved to the top-level README (or somewhere else).
> Also the content could be elaborated for newdevs.



--
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-9509) Refine lucene/BUILD.md (move Solr related contents to top-level README)

[Uwe Schindler (Jira)]

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

Uwe Schindler commented on LUCENE-9509:
---

The way how to build documentation looks strange.

First of all, we should change the build, so "gradlew documentation" also 
builds ref guide. And the readme should mention this instead of a weird 
"buildSite".

> Refine lucene/BUILD.md (move Solr related contents to top-level README)
> ---
>
> Key: LUCENE-9509
> URL: https://issues.apache.org/jira/browse/LUCENE-9509
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0)
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Current lucene/BUILD.md is somehow mixed-up with information for Solr 
> developers, this is wrong place for them. Solr related information/tips 
> should be moved to the top-level README (or somewhere else).
> Also the content could be elaborated for newdevs.



--
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-9507) Custom order for leaves in DirectoryReader, IndexWriter and searcher

[Jim Ferenczi (Jira)]

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

Jim Ferenczi commented on LUCENE-9507:
--

Thanks for looking [~sokolov] , I was thinking that the merge policy would be 
just a thin wrapper that sort whichever segments are chosen. 

> Custom order for leaves in DirectoryReader, IndexWriter and searcher
> 
>
> Key: LUCENE-9507
> URL: https://issues.apache.org/jira/browse/LUCENE-9507
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Jim Ferenczi
>Priority: Minor
>
> Now that we're able [to skip documents efficiently when sorting by a numeric 
> field|https://issues.apache.org/jira/browse/LUCENE-9280], I was wondering if 
> we could optimize sorted queries further by also sorting the leaf readers 
> based on the primary sort.
> For time-based indices in Elasticsearch, we've implemented an optimization 
> that does that at query time. If the query is sorted by a numeric docvalue 
> field, prior to search, we sort the leaves according to the query sort. When 
> sorting by timestamp this small optimization can have a big impact since 
> early termination can be reached much faster if the sort values in the 
> segments don't overlap too much. Applying this optimization at query time is 
> challenging , it has the benefit to work on any numeric field sort and order 
> but it requires to use a multi-reader that will reorganize the segments. It 
> can also be deceptive that after a force merge to 1 segment sorted queries 
> may be slower since there is nothing to sort anymore.
> So, another option that I look at is to add the ability to provide a leaf 
> order directly in the IndexWriter and DirectoryReader. That could be similar 
> to an index sort or even complementary to it since sorting segments based on 
> the index sort could also help at query time. For time-based indices that 
> cannot afford index sorting but have lots of sorted queries on timestamp, 
> forcing the order of segments could speed up sorted queries significantly. 
> The advantage of forcing a single leaf sort in the writer/reader is that we 
> can also use it to influence the merges by putting the segments with the 
> highest value first. That would help with the case of indices that are merged 
> to a single segment but would like to keep the sorted queries fast but also 
> for the multi-segments case since big segments would have more chance to have 
> highest values first 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-14837) prometheus-exporter: different metrics ports publishes mixed metrics

[Fadi Mohsen (Jira)]

Fadi Mohsen created SOLR-14837:
--

 Summary: prometheus-exporter: different metrics ports publishes 
mixed metrics
 Key: SOLR-14837
 URL: https://issues.apache.org/jira/browse/SOLR-14837
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Fadi Mohsen


when calling SolrExporter.main "pro-grammatically"/"same JVM" with two 
different solr masters asking to publish the metrics on two different ports, 
the metrics are being mixed on both metric endpoints from the two solr masters.

This was tracked down to a static variable called *defaultRegistry*:
https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/SolrExporter.java#L86

removing the static keyword fixes the issue.



--
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-14837) prometheus-exporter: different metrics ports publishes mixed metrics

[Fadi Mohsen (Jira)]

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

Fadi Mohsen updated SOLR-14837:
---
Affects Version/s: 8.6.2

> prometheus-exporter: different metrics ports publishes mixed metrics
> 
>
> Key: SOLR-14837
> URL: https://issues.apache.org/jira/browse/SOLR-14837
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.6.2
>Reporter: Fadi Mohsen
>Priority: Minor
>
> when calling SolrExporter.main "pro-grammatically"/"same JVM" with two 
> different solr masters asking to publish the metrics on two different ports, 
> the metrics are being mixed on both metric endpoints from the two solr 
> masters.
> This was tracked down to a static variable called *defaultRegistry*:
> https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/SolrExporter.java#L86
> removing the static keyword fixes the issue.



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

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

[jira] [Updated] (LUCENE-9509) Refine lucene/BUILD.md (move Solr related contents to top-level README)

[Tomoko Uchida (Jira)]

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

Tomoko Uchida updated LUCENE-9509:
--
Attachment: LUCENE-9509-fix-gradle-command-documentation.patch

> Refine lucene/BUILD.md (move Solr related contents to top-level README)
> ---
>
> Key: LUCENE-9509
> URL: https://issues.apache.org/jira/browse/LUCENE-9509
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-9509-fix-gradle-command-documentation.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Current lucene/BUILD.md is somehow mixed-up with information for Solr 
> developers, this is wrong place for them. Solr related information/tips 
> should be moved to the top-level README (or somewhere else).
> Also the content could be elaborated for newdevs.



--
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-9509) Refine lucene/BUILD.md (move Solr related contents to top-level README)

[ASF subversion and git services (Jira)]

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

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

Commit 7d0a0b96e06ef26130fa2d9cc860ca75ba430bbc in lucene-solr's branch 
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7d0a0b9 ]

LUCENE-9509: fix generating documentation command for Solr


> Refine lucene/BUILD.md (move Solr related contents to top-level README)
> ---
>
> Key: LUCENE-9509
> URL: https://issues.apache.org/jira/browse/LUCENE-9509
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-9509-fix-gradle-command-documentation.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Current lucene/BUILD.md is somehow mixed-up with information for Solr 
> developers, this is wrong place for them. Solr related information/tips 
> should be moved to the top-level README (or somewhere else).
> Also the content could be elaborated for newdevs.



--
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-9509) Refine lucene/BUILD.md (move Solr related contents to top-level README)

[Tomoko Uchida (Jira)]

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

Tomoko Uchida commented on LUCENE-9509:
---

I changed the command to build documentation to {{./gradlew -p solr 
documentation}}. (I specified the project by "-p solr" since the section in the 
README is about Solr.)
{quote}First of all, we should change the build, so "gradlew documentation" 
also builds ref guide.
{quote}
Another issue may be needed...

> Refine lucene/BUILD.md (move Solr related contents to top-level README)
> ---
>
> Key: LUCENE-9509
> URL: https://issues.apache.org/jira/browse/LUCENE-9509
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-9509-fix-gradle-command-documentation.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Current lucene/BUILD.md is somehow mixed-up with information for Solr 
> developers, this is wrong place for them. Solr related information/tips 
> should be moved to the top-level README (or somewhere else).
> Also the content could be elaborated for newdevs.



--
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-14838) Atomic updates when the destination for a copyField has stored=true

[Erick Erickson (Jira)]

Erick Erickson created SOLR-14838:
-

 Summary: Atomic updates when the destination for a copyField has 
stored=true
 Key: SOLR-14838
 URL: https://issues.apache.org/jira/browse/SOLR-14838
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson


Raising for discussion. Currently, when using atomic updates, one restriction 
is that the destination for copyField directives must have stored=false or you 
wind up with duplicate entries.

On the surface and just glancing at AtomicUpdateDocumentMerger, it seems like 
we could just skip adding fields to the "toDoc" if they were the destinations 
of a copyField directive.

Or does this run afoul of things like Real Time Get?

[~yonik] do you recall anything about this?



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

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

[jira] [Commented] (SOLR-14768) Error 500 on PDF extraction: java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts

[Joe Doupnik (Jira)]

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

Joe Doupnik commented on SOLR-14768:


    git is already installed and working. Thus one suspects the Solr 
script(s) involved has(ve) problem(s). We may note that doing a "grep 
-iR git.exe *" on both solr 8.5.0 and 8.6.1 source file distributions 
produce the same results that  symbol "git.exe" appears only in the same 
lucene/common-built.xml file. Thus whatever may be the real cause of the 
8.6 test script failure it is well hidden.
     Thanks,
     Joe D.



> Error 500 on PDF extraction: java.lang.NoClassDefFoundError: 
> org/eclipse/jetty/server/MultiParts
> 
>
> Key: SOLR-14768
> URL: https://issues.apache.org/jira/browse/SOLR-14768
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
>Affects Versions: 8.6, 8.6.1
>Reporter: Markus Kalkbrenner
>Assignee: David Smiley
>Priority: Major
> Attachments: Solr v8.6.x fails with multipart MIME in commands.eml, 
> Solr v8.6.x fails with multipart MIME in commands.eml, Solr v8.6.x fails with 
> multipart MIME in commands.eml
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> See [https://www.mail-archive.com/solr-user@lucene.apache.org/msg152182.html]
> The integration tests of the solarium PHP library and the integration tests 
> of the Search API Solr Drupal module both fail on PDF extraction if executed 
> on Solr 8.6.
> They still work on Solr 8.5.1 an earlier versions.
> {quote}2020-08-20 12:30:35.279 INFO (qtp855700733-19) [ x:5f3e6ce2810ef] 
> o.a.s.u.p.LogUpdateProcessorFactory [5f3e6ce2810ef] webapp=/solr 
> path=/update/extract 
> params=\{json.nl=flat&commitWithin=0&omitHeader=false&resource.name=testpdf.pdf&literal.id=extract-test&commit=true&extractOnly=false&uprefix=attr_&wt=json}{add=[extract-test
>  (1675547519474466816)],commit=} 0 957
> solr8_1 | 2020-08-20 12:30:35.280 WARN (qtp855700733-19) [ ] 
> o.e.j.s.HttpChannel /solr/5f3e6ce2810ef/update/extract => 
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts
> solr8_1 | at 
> org.apache.solr.servlet.SolrRequestParsers.cleanupMultipartFiles(SolrRequestParsers.java:624)
> solr8_1 | java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts
> solr8_1 | at 
> org.apache.solr.servlet.SolrRequestParsers.cleanupMultipartFiles(SolrRequestParsers.java:624)
>  ~[?:?]
> solr8_1 | at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:443)
>  ~[?:?]
> solr8_1 | at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
>  ~[?:?]
> solr8_1 | at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
>  ~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545) 
> ~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) 
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590) 
> ~[jetty-security-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
>  ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
>  ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
>  ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
>  ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
>  ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
>  ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485) 
> ~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
>  ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
>  ~[jetty-server-9.4.27.v20200227.jar:

[jira] [Commented] (LUCENE-9509) Refine lucene/BUILD.md (move Solr related contents to top-level README)

[Uwe Schindler (Jira)]

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

Uwe Schindler commented on LUCENE-9509:
---

Thanks!

> Refine lucene/BUILD.md (move Solr related contents to top-level README)
> ---
>
> Key: LUCENE-9509
> URL: https://issues.apache.org/jira/browse/LUCENE-9509
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-9509-fix-gradle-command-documentation.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Current lucene/BUILD.md is somehow mixed-up with information for Solr 
> developers, this is wrong place for them. Solr related information/tips 
> should be moved to the top-level README (or somewhere else).
> Also the content could be elaborated for newdevs.



--
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-14839) Address Alias impl.

[Mark Robert Miller (Jira)]

Mark Robert Miller created SOLR-14839:
-

 Summary: Address Alias impl.
 Key: SOLR-14839
 URL: https://issues.apache.org/jira/browse/SOLR-14839
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mark Robert Miller






--
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-14825) Wrap up async issues and tests.

[Mark Robert Miller (Jira)]

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

Mark Robert Miller commented on SOLR-14825:
---

I think I've gotten the majority of the pressing issues around async.

In the past, I also added automatic cleanup of async id's, that manual stuff is 
yuck, but I won't consider additional items like that as part of this 
particular issue.

> Wrap up async issues and tests.
> ---
>
> Key: SOLR-14825
> URL: https://issues.apache.org/jira/browse/SOLR-14825
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Robert Miller
>Priority: Major
>
> Tim recently fixed an issue with async, but I think there is a bit more to 
> look at. One thing I have not gotten to this time is making sure it doesn't 
> register as complete until the replicas are seen exactly properly in the 
> state. Also, the client would need to see that, which is a bit trickier.



--
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-14834) Update all public-visible links from wiki.apache.org to RefGuide or cwiki

[Alexandre Rafalovitch (Jira)]

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

Alexandre Rafalovitch updated SOLR-14834:
-
Fix Version/s: master (9.0)

> Update all public-visible links from wiki.apache.org to RefGuide or cwiki
> -
>
> Key: SOLR-14834
> URL: https://issues.apache.org/jira/browse/SOLR-14834
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Major
> Fix For: master (9.0)
>
>
> There is no point pointing at the old wiki and it is not reasonable to expect 
> users to try to track the links to the new references. Especially since 
> hosted RefGuide does not allow full-text search yet.
> Do this only for information visible to the users, the rest can be a separate 
> JIRA.
> I am aware that we don't yet support RefGuide version locks in URLs (see 
> SOLR-11143), but even doing latest-version links is already useful and will 
> at least do the hard part of resolving all the corresponding URLs from old 
> wiki to RefGuide (or cwiki if any).



--
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-14834) Update all public-visible links from wiki.apache.org to RefGuide or cwiki

[Alexandre Rafalovitch (Jira)]

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

Alexandre Rafalovitch updated SOLR-14834:
-
Priority: Blocker  (was: Major)

> Update all public-visible links from wiki.apache.org to RefGuide or cwiki
> -
>
> Key: SOLR-14834
> URL: https://issues.apache.org/jira/browse/SOLR-14834
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Blocker
> Fix For: master (9.0)
>
>
> There is no point pointing at the old wiki and it is not reasonable to expect 
> users to try to track the links to the new references. Especially since 
> hosted RefGuide does not allow full-text search yet.
> Do this only for information visible to the users, the rest can be a separate 
> JIRA.
> I am aware that we don't yet support RefGuide version locks in URLs (see 
> SOLR-11143), but even doing latest-version links is already useful and will 
> at least do the hard part of resolving all the corresponding URLs from old 
> wiki to RefGuide (or cwiki if any).



--
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-14834) Update all public-visible links from wiki.apache.org to RefGuide or cwiki

[Alexandre Rafalovitch (Jira)]

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

Alexandre Rafalovitch commented on SOLR-14834:
--

I am marking this as a blocker for 9 that I will resolve. The reason for such 
marking is that a number of files this affects are being removed/modified by 
other issues (e.g. SOLR-14792). Therefore, I can progress on this task for 
other files, but its completion will depend on the leftover files from those 
other issues.

> Update all public-visible links from wiki.apache.org to RefGuide or cwiki
> -
>
> Key: SOLR-14834
> URL: https://issues.apache.org/jira/browse/SOLR-14834
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Blocker
> Fix For: master (9.0)
>
>
> There is no point pointing at the old wiki and it is not reasonable to expect 
> users to try to track the links to the new references. Especially since 
> hosted RefGuide does not allow full-text search yet.
> Do this only for information visible to the users, the rest can be a separate 
> JIRA.
> I am aware that we don't yet support RefGuide version locks in URLs (see 
> SOLR-11143), but even doing latest-version links is already useful and will 
> at least do the hard part of resolving all the corresponding URLs from old 
> wiki to RefGuide (or cwiki if any).



--
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] sigram commented on pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.

[GitBox]

sigram commented on pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#issuecomment-688426745


   FWIW, the scheduler part is now in PR 1831.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] sigram commented on a change in pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.

[GitBox]

sigram commented on a change in pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#discussion_r484517789



##
File path: solr/core/src/java/org/apache/solr/cluster/events/ScheduledEvent.java
##
@@ -0,0 +1,30 @@
+/*
+ * 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.solr.cluster.events;
+
+/**
+ *
+ */
+public interface ScheduledEvent extends ClusterEvent {

Review comment:
   > For some context, almost all devops engineers I've interacted with do 
not trust Solr to carry out these things in an unsupervised manner
   
   IIUIC this objection was to the scheduler part. This is now removed from 
this PR - changes here are related purely to the facility to generate 
cluster-state related events and the API for registering listeners to these 
events.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Created] (SOLR-14840) Convert Overseer Google doc to asciidoc for addition to Git repo

[Cassandra Targett (Jira)]

Cassandra Targett created SOLR-14840:


 Summary: Convert Overseer Google doc to asciidoc for addition to 
Git repo
 Key: SOLR-14840
 URL: https://issues.apache.org/jira/browse/SOLR-14840
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Reporter: Cassandra Targett


Back in April [~ilan] shared via the mailing list a Google doc he had written 
which provided extensive documentation of the Overseer. It's an impressive 
document, and one we should preserve in the repo for other developers to use.

I recently offered to convert the Google doc to Asciidoc format to add it to 
the {{solr/dev-docs}} directory, so this issue is mostly so I can make a branch 
for Ilan (and others) to review.

Mailing list thread: 
https://lists.apache.org/thread.html/rf41ae1356bd2e4e68b3c3d835c5e368493ae0ee14a024402c88c795e%40%3Cdev.lucene.apache.org%3E

Original Google doc: 
https://docs.google.com/document/d/1KTHq3noZBVUQ7QNuBGEhujZ_duwTVpAsvN3Nz5anQUY/edit



--
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-14841) Update RefGuide with information in config files

[Alexandre Rafalovitch (Jira)]

Alexandre Rafalovitch created SOLR-14841:


 Summary: Update RefGuide with information in config files
 Key: SOLR-14841
 URL: https://issues.apache.org/jira/browse/SOLR-14841
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Reporter: Alexandre Rafalovitch


The configuration (and other files) have information that is missing in 
Reference Guide. This is an issue to try adding various discovered pieces of 
wisdom into the relevant parts of RefGuide to ensure it is the primary 
(non-code) source of information.



--
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-14841) Update RefGuide with information in config files

[Alexandre Rafalovitch (Jira)]

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

Alexandre Rafalovitch reassigned SOLR-14841:


Assignee: Alexandre Rafalovitch

> Update RefGuide with information in config files
> 
>
> Key: SOLR-14841
> URL: https://issues.apache.org/jira/browse/SOLR-14841
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Major
>
> The configuration (and other files) have information that is missing in 
> Reference Guide. This is an issue to try adding various discovered pieces of 
> wisdom into the relevant parts of RefGuide to ensure it is the primary 
> (non-code) source of information.



--
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-14840) Convert Overseer Google doc to asciidoc for addition to Git repo

[Cassandra Targett (Jira)]

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

Cassandra Targett commented on SOLR-14840:
--

Here is the branch: 
https://github.com/apache/lucene-solr/tree/jira/solr-14840/solr/dev-docs/overseer

Since the original Google doc had images, I put the new overseer.adoc into a 
directory under the dev-docs directory, and the images in a directory under 
that. In Github the new file displays quite nicely.

The original Google doc had a section which had been crossed out - I omitted 
that from this conversion. Otherwise, however, the content should be identical. 
There might be a few lingering format problems that need to be fixed.

Ilan's original highlighted problematic areas with a warning symbol next to the 
paragraph. In the conversion, I put those into Asciidoc's warning style block.

I think it's worth considering if this document should be broken up into 
smaller docs (per class maybe?). I don't have a particular opinion about that 
at this time, but think it's worth a thought in general.

> Convert Overseer Google doc to asciidoc for addition to Git repo
> 
>
> Key: SOLR-14840
> URL: https://issues.apache.org/jira/browse/SOLR-14840
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Back in April [~ilan] shared via the mailing list a Google doc he had written 
> which provided extensive documentation of the Overseer. It's an impressive 
> document, and one we should preserve in the repo for other developers to use.
> I recently offered to convert the Google doc to Asciidoc format to add it to 
> the {{solr/dev-docs}} directory, so this issue is mostly so I can make a 
> branch for Ilan (and others) to review.
> Mailing list thread: 
> https://lists.apache.org/thread.html/rf41ae1356bd2e4e68b3c3d835c5e368493ae0ee14a024402c88c795e%40%3Cdev.lucene.apache.org%3E
> Original Google doc: 
> https://docs.google.com/document/d/1KTHq3noZBVUQ7QNuBGEhujZ_duwTVpAsvN3Nz5anQUY/edit



--
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-14829) Default components are missing facet_module and terms in documentation

[Cassandra Targett (Jira)]

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

Cassandra Targett commented on SOLR-14829:
--

The docs changes are fine from my POV, someone just needs to confirm that terms 
and facet_module are both really enabled by default.

bq. I think we should seriously think of streamlining this going forward – 
there is no reason why this inconsistency should persist.

I agree, and it's something that's been discussed many times over the years. A 
simple explanation (IMO) is that it was someone's vision that {{facet_module}} 
would replace {{facet}} at some point but as a project we haven't progressed 
very far toward that goal. 

> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, examples
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by 
> default is missing the {{facet_module}} and {{terms}} components. The terms 
> component is instead listed under "other useful components", while the 
> {{FacetModule}} is never listed anywhere in the documentation, despite it 
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why 
> JSON-based faceting was not working with my setup, after taking a glance at 
> the {{SearchHandler}} source code based on a hunch, it became clear that my 
> custom list of search components (created based on the list in the reference 
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some 
> other issues with the naming/documentation around the two faceting APIs that 
> may be worth discussing:
>  * The names {{facet_module}} / {{FacetModule}} are very misleading, since 
> the documentation is always talking about the "JSON Facet API", but the term 
> "JSON" does not appear in the name of the component nor does the component 
> have any documentation attached that mentions this
>  * Why is the {{FacetModule}} class located in the {{search.facet}} package 
> while every single other search component included in the core is located in 
> the {{handler.component}} package?



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

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

[GitHub] [lucene-solr] dweiss commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

dweiss commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688492819


   You're right, Uwe - the subproject scan inclusion sucks. I don't know how to 
avoid it in an elegant way. This could be done with worker API as well but it's 
not the same - per project tasks are more cache friendly and run in parallel 
without any special hackery.
   
   I'll give it another thought, thanks for the review and fixes!



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Commented] (SOLR-12963) change default for 'uninvertible' to 'false' (dependent on new schema 'version')

[Alexandre Rafalovitch (Jira)]

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

Alexandre Rafalovitch commented on SOLR-12963:
--

Could we implement this for 9 (version bump and default change)? I just checked 
both our default configsets and we don't have this field actually set to false 
anywhere. So, we are not following our own RefGuide "strongly encouraged" 
advice.

Also, we also have 3 instances of *uninvertable* in the codebase, fortunately 
just in comments.

> change default for 'uninvertible' to 'false' (dependent on new schema 
> 'version')
> 
>
> Key: SOLR-12963
> URL: https://issues.apache.org/jira/browse/SOLR-12963
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-12963.patch
>
>
> We should consider changing the default behavior of the {{uninvertible}} 
> field option to be dependnt on the schema {{version}} property, such that 
> moving forward the fields/fieldtypes will default to {{uninvertible == 
> false}} unless an explicit {{uninvertible=true}} is specified by the user.
> There are a lot of considerations regarding the existing behavior of 
> functionality (like faceting) when the (effective) value of {{uninvertible}} 
> is false because we move forward with changing this in a way that could 
> suprise/confuse new users or existing users w/ long heald expectations that 
> certain behavior would just "work" w/o understanding that was because of 
> FieldCache/uninversion.
> See parent issue for more background/discussion.



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

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

[jira] [Created] (LUCENE-9511) Include StoredFieldsWriter in DWPT accounting

[Simon Willnauer (Jira)]

Simon Willnauer created LUCENE-9511:
---

 Summary: Include StoredFieldsWriter in DWPT accounting
 Key: LUCENE-9511
 URL: https://issues.apache.org/jira/browse/LUCENE-9511
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Simon Willnauer


StoredFieldsWriter might consume some heap space memory that can have a 
significant impact on decisions made in the IW if writers should be stalled or 
DWPTs should be flushed if memory settings are small in IWC and flushes are 
frequent. We should add some accounting to the StoredFieldsWriter since it's 
part of the DWPT lifecycle and not just present during flush.

Our nightly builds ran into some OOMs due to the large chunk size used in the 
CompressedStoredFieldsFormat. The reason are very frequent flushes due to small 
maxBufferedDocs which causes 300+ DWPTs to be blocked for flush causing 
ultimately an OOM exception.

{noformat}
 
 NOTE: reproduce with: ant test  -Dtestcase=TestIndexingSequenceNumbers 
-Dtests.method=testStressConcurrentCommit -Dtests.seed=A04943A98C8E2954 
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=vo-001 -Dtests.timezone=Africa/Ouagadougou -Dtests.asserts=true 
-Dtests.file.encoding=UTF8*06:06:15*[junit4] ERROR107s J3 | 
TestIndexingSequenceNumbers.testStressConcurrentCommit <<<*06:06:15*
[junit4]> Throwable #1: org.apache.lucene.store.AlreadyClosedException: 
this IndexWriter is closed*06:06:15*[junit4]>  at 
org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:876)*06:06:15*  
  [junit4]>  at 
org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:890)*06:06:15*  
  [junit4]>  at 
org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3727)*06:06:15*
[junit4]> at 
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressConcurrentCommit(TestIndexingSequenceNumbers.java:228)*06:06:15*
[junit4]>  at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)*06:06:15*[junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)*06:06:15*
[junit4]>  at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)*06:06:15*
[junit4]>  at 
java.base/java.lang.reflect.Method.invoke(Method.java:566)*06:06:15*
[junit4]>at 
java.base/java.lang.Thread.run(Thread.java:834)*06:06:15*[junit4]> 
Caused by: java.lang.OutOfMemoryError: Java heap space*06:06:15*[junit4]
> at __randomizedtesting.SeedInfo.seed([A04943A98C8E2954]:0)*06:06:15*  
  [junit4]>   at 
org.apache.lucene.store.GrowableByteArrayDataOutput.(GrowableByteArrayDataOutput.java:46)*06:06:15*
[junit4]>   at 
org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.(CompressingStoredFieldsWriter.java:111)*06:06:15*
[junit4]> at 
org.apache.lucene.codecs.compressing.CompressingStoredFieldsFormat.fieldsWriter(CompressingStoredFieldsFormat.java:130)*06:06:15*
[junit4]>   at 
org.apache.lucene.codecs.lucene87.Lucene87StoredFieldsFormat.fieldsWriter(Lucene87StoredFieldsFormat.java:141)*06:06:15*
[junit4]>at 
org.apache.lucene.codecs.asserting.AssertingStoredFieldsFormat.fieldsWriter(AssertingStoredFieldsFormat.java:48)*06:06:15*
[junit4]>  at 
org.apache.lucene.index.StoredFieldsConsumer.initStoredFieldsWriter(StoredFieldsConsumer.java:39)*06:06:15*
[junit4]> at 
org.apache.lucene.index.StoredFieldsConsumer.startDocument(StoredFieldsConsumer.java:46)*06:06:15*
[junit4]>  at 
org.apache.lucene.index.DefaultIndexingChain.startStoredFields(DefaultIndexingChain.java:426)*06:06:15*
[junit4]> at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:462)*06:06:15*
[junit4]>   at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocuments(DocumentsWriterPerThread.java:233)*06:06:15*
[junit4]>   at 
org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:419)*06:06:15*
[junit4]> at 
org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1470)*06:06:15*
[junit4]>at 
org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1463)*06:06:15*
[junit4]>at 
org.apache.lucene.index.TestIndexingSequenceNumbers$2.run(TestIndexingSequenceNumbers.java:206)Throwable
 #2: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
uncaught exception in thread: Thread[id=1140, name=Thread-1095, state=RUNNABLE, 
group=TGRP-TestIndexingSequenceNumbers]*06:06:15*[junit4]> Caused by: 
java.lang.OutOfMemoryError: Java heap spaceThrowable #3: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exceptio

[GitHub] [lucene-solr] s1monw opened a new pull request #1839: LUCENE-9511: Include StoredFieldsWriter in DWPT accounting

[GitBox]

s1monw opened a new pull request #1839:
URL: https://github.com/apache/lucene-solr/pull/1839


   StoredFieldsWriter might consume some heap space memory that
   can have a significant impact on decisions made in the IW if
   writers should be stalled or DWPTs should be flushed if memory
   settings are small in IWC and flushes are frequent. This change adds
   RAM accounting to the StoredFieldsWriter since it's part of the
   DWPT lifecycle and not just present during flush.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Commented] (SOLR-14815) Remove added Ignores to tests that still have them

[Mark Robert Miller (Jira)]

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

Mark Robert Miller commented on SOLR-14815:
---

I'm starting to actually work on this for real.

There is a bit of work here and there, but a lot of the tests will come back 
online pretty easily.

I almost never Ignore a test because it's broken with some change I made - I 
Ignored them due to being flakey as I drove towards a solid test run. Of 
course, as you develop with those tests off, you may do things that they don't 
like or would have caught. Or sometimes, making other stuff better makes them 
fail consistently instead of rarely. So most of the work is around extending 
the larger changes (Overseer, Collections API, some other more minor stuff) to 
work with these tests. Often, whatever made them flakey is addressed by this 
point or much easier to address now.

So I won't run through them *all* right now, but I'll hit a big chunk of the 
ones I think make sense.

> Remove added Ignores to tests that still have them
> --
>
> Key: SOLR-14815
> URL: https://issues.apache.org/jira/browse/SOLR-14815
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
>




--
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] uschindler commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688514787


   Hi,
   I was able to prevent gradle from scanning duplicates:
   
   ```
   // Don't go into subprojects (scanned separately).
   childProjects.keySet().each{
 exclude "${it}/**"
   }
   ```



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler edited a comment on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler edited a comment on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688514787


   Hi,
   I was able to prevent gradle from scanning duplicates:
   
   ```gradle
   // Don't go into subprojects (scanned separately).
   childProjects.keySet().each{
 exclude "${it}/**"
   }
   ```



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688516919


   Hi,
   
   this now passes build, but speed is on my laptop (Windows 10) only sligthly 
faster: 32s before, 24s with this PR (including configuration and without 
gradle daemon).
   
   Another approach to fix this would be to only put some dirs on the include 
list (like `src/**`) and don't have so many excludes. The reason why it's the 
other way round ("scan everything, except..."): The original Ant task was setup 
like this to just scan all text files and source files splattered around in the 
ant build for invalid source patterns. It should detect any violation, anywhere 
(in build files, xml files, source code, resources,... everywhere). So the idea 
is to scan as much as possible and put outliers on a exclude list.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688517196


   The reason why the speed difference is so small may be related in the fact 
that "project configuration" (collecting those file trees, one for each 
project) take much longer than the actual scanning.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] vthacker merged pull request #1816: LUCENE-9497: Integerate Error Prone ( Static Analysis Tool ) during compilation

[GitBox]

vthacker merged pull request #1816:
URL: https://github.com/apache/lucene-solr/pull/1816


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Commented] (LUCENE-9497) Integerate Error Prone ( Static Analysis Tool ) during compilation

[ASF subversion and git services (Jira)]

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

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

Commit 121b262389691a10607e22ff025504e6ee3a9134 in lucene-solr's branch 
refs/heads/master from Varun Thacker
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=121b262 ]

LUCENE-9497: Integerate Error Prone ( Static Analysis Tool ) during compilation 
(#1816)

LUCENE-9497:  Integrate Error Prone, a static analysis tool during compilation

> Integerate Error Prone ( Static Analysis Tool ) during compilation
> --
>
> Key: LUCENE-9497
> URL: https://issues.apache.org/jira/browse/LUCENE-9497
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Varun Thacker
>Priority: Minor
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> Integrate [https://github.com/google/error-prone] during compilation of our 
> source code to catch mistakes



--
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-9497) Integerate Error Prone ( Static Analysis Tool ) during compilation

[ASF subversion and git services (Jira)]

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

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

Commit 121b262389691a10607e22ff025504e6ee3a9134 in lucene-solr's branch 
refs/heads/master from Varun Thacker
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=121b262 ]

LUCENE-9497: Integerate Error Prone ( Static Analysis Tool ) during compilation 
(#1816)

LUCENE-9497:  Integrate Error Prone, a static analysis tool during compilation

> Integerate Error Prone ( Static Analysis Tool ) during compilation
> --
>
> Key: LUCENE-9497
> URL: https://issues.apache.org/jira/browse/LUCENE-9497
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Varun Thacker
>Priority: Minor
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> Integrate [https://github.com/google/error-prone] during compilation of our 
> source code to catch mistakes



--
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] vthacker closed pull request #1828: LUCENE-9497: add google error prone checks

[GitBox]

vthacker closed pull request #1828:
URL: https://github.com/apache/lucene-solr/pull/1828


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688524908


   I refactored the config a bit (project-specific excludes moved to separate 
configure-blocks). I also added `*.md` to the list of scanned files.
   
   Looks ready now.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] noblepaul merged pull request #1815: SOLR-14151: Bug fixes

[GitBox]

noblepaul merged pull request #1815:
URL: https://github.com/apache/lucene-solr/pull/1815


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Commented] (SOLR-14151) Make schema components load from packages

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14151:


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

SOLR-14151: Bug fixes (#1815)



> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Labels: packagemanager
> Fix For: 8.7
>
>  Time Spent: 12h 40m
>  Remaining Estimate: 0h
>
> Example:
> {code:xml}
>  
> 
>   
>generateNumberParts="0" catenateWords="0"
>   catenateNumbers="0" catenateAll="0"/>
>   
>   
> 
>   
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed, 
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components 
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API



--
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-14097) coreRootDirectory should be solr_home/cores

[Alexandre Rafalovitch (Jira)]

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

Alexandre Rafalovitch updated SOLR-14097:
-
Attachment: solr_test_no_dir.log

> coreRootDirectory should be solr_home/cores
> ---
>
> Key: SOLR-14097
> URL: https://issues.apache.org/jira/browse/SOLR-14097
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Blocker
> Fix For: master (9.0)
>
> Attachments: solr_test_no_dir.log
>
>
> The coreRootDirectory defaults to be solr_home.  Instead it should be a new 
> directory dedicated to solr cores, like solr_home/cores.  Using solr_home 
> directly has potential to clash with other things in that directory like 
> "lib" and "configsets".



--
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-14613) Provide a clean API for pluggable replica assignment implementations

[Noble Paul (Jira)]

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

Noble Paul commented on SOLR-14613:
---

I think we have addressed the API surface area issue. 

The only outstanding issue is configuring this in solr.xml. 



> Provide a clean API for pluggable replica assignment implementations
> 
>
> Key: SOLR-14613
> URL: https://issues.apache.org/jira/browse/SOLR-14613
> Project: Solr
>  Issue Type: Improvement
>  Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Ilan Ginzburg
>Priority: Major
>  Time Spent: 36h 10m
>  Remaining Estimate: 0h
>
> As described in SIP-8 the current autoscaling Policy implementation has 
> several limitations that make it difficult to use for very large clusters and 
> very large collections. SIP-8 also mentions the possible migration path by 
> providing alternative implementations of the placement strategies that are 
> less complex but more efficient in these very large environments.
> We should review the existing APIs that the current autoscaling engine uses 
> ({{SolrCloudManager}} , {{AssignStrategy}} , {{Suggester}} and related 
> interfaces) to see if they provide a sufficient and minimal API for plugging 
> in alternative autoscaling placement strategies, and if necessary refactor 
> the existing APIs.
> Since these APIs are internal it should be possible to do this without 
> breaking back-compat.



--
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-14097) coreRootDirectory should be solr_home/cores

[Alexandre Rafalovitch (Jira)]

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

Alexandre Rafalovitch commented on SOLR-14097:
--

This seems broken in 8.6.1.

Attempts:
 # Don't create the *cores* directory
 ## edit server/solr/solr.xml to add ` cores/`
 ## bin/solr start - works
 ## bin/solr create_core -c test_no_dir
 ## Result: huge exception stack: CoreContainer is either not initialized or 
shutting down.
 # Create *cores* directory
 ## same solr.xml
 ## create directory server/solr/cores
 ## start server
 ## bin/solr create_core -c test_yes_dir
 ## Result: No exception, but a message: ERROR: Error CREATEing SolrCore 
'test_yes_dir': Unable to create core [test_yes_dir] Caused by: Can't find 
resource 'solrconfig.xml' in classpath or 
'/Users/arafalov/Projects/solr/solr-8.6.1/server/solr/cores/test_yes_dir'
 ## Result: server/solr/cores/test_yes_dir/ is created but it is empty

 

 

 

 

> coreRootDirectory should be solr_home/cores
> ---
>
> Key: SOLR-14097
> URL: https://issues.apache.org/jira/browse/SOLR-14097
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Blocker
> Fix For: master (9.0)
>
> Attachments: solr_test_no_dir.log
>
>
> The coreRootDirectory defaults to be solr_home.  Instead it should be a new 
> directory dedicated to solr cores, like solr_home/cores.  Using solr_home 
> directly has potential to clash with other things in that directory like 
> "lib" and "configsets".



--
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-14097) coreRootDirectory should be solr_home/cores

[Alexandre Rafalovitch (Jira)]

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

Alexandre Rafalovitch updated SOLR-14097:
-
Attachment: solr_test_yes_dir.log

> coreRootDirectory should be solr_home/cores
> ---
>
> Key: SOLR-14097
> URL: https://issues.apache.org/jira/browse/SOLR-14097
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Blocker
> Fix For: master (9.0)
>
> Attachments: solr_test_no_dir.log, solr_test_yes_dir.log
>
>
> The coreRootDirectory defaults to be solr_home.  Instead it should be a new 
> directory dedicated to solr cores, like solr_home/cores.  Using solr_home 
> directly has potential to clash with other things in that directory like 
> "lib" and "configsets".



--
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-14097) coreRootDirectory should be solr_home/cores

[Alexandre Rafalovitch (Jira)]

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

Alexandre Rafalovitch updated SOLR-14097:
-
Attachment: solr_yes_trace.log

> coreRootDirectory should be solr_home/cores
> ---
>
> Key: SOLR-14097
> URL: https://issues.apache.org/jira/browse/SOLR-14097
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Blocker
> Fix For: master (9.0)
>
> Attachments: solr_test_no_dir.log, solr_test_yes_dir.log, 
> solr_yes_trace.log
>
>
> The coreRootDirectory defaults to be solr_home.  Instead it should be a new 
> directory dedicated to solr cores, like solr_home/cores.  Using solr_home 
> directly has potential to clash with other things in that directory like 
> "lib" and "configsets".



--
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-14097) coreRootDirectory should be solr_home/cores

[Alexandre Rafalovitch (Jira)]

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

Alexandre Rafalovitch commented on SOLR-14097:
--

Argh, it seems that this is because the code uses solr.home and is not aware of 
coreRootDirectory.

But that is complicated because coreRootDirectory is not reported either by 
/solr/admin/info/system 

So, it is a multi-step fix here.

> coreRootDirectory should be solr_home/cores
> ---
>
> Key: SOLR-14097
> URL: https://issues.apache.org/jira/browse/SOLR-14097
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Blocker
> Fix For: master (9.0)
>
> Attachments: solr_test_no_dir.log, solr_test_yes_dir.log, 
> solr_yes_trace.log
>
>
> The coreRootDirectory defaults to be solr_home.  Instead it should be a new 
> directory dedicated to solr cores, like solr_home/cores.  Using solr_home 
> directly has potential to clash with other things in that directory like 
> "lib" and "configsets".



--
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-14151) Make schema components load from packages

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14151:


Commit b46285c686faa672ccf4c24a7812c49b7ad8b939 in lucene-solr's branch 
refs/heads/branch_8x from noblepaul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b46285c ]

SOLR-14151: Bug fixes


> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Labels: packagemanager
> Fix For: 8.7
>
>  Time Spent: 12h 40m
>  Remaining Estimate: 0h
>
> Example:
> {code:xml}
>  
> 
>   
>generateNumberParts="0" catenateWords="0"
>   catenateNumbers="0" catenateAll="0"/>
>   
>   
> 
>   
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed, 
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components 
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API



--
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-14151) Make schema components load from packages

[Noble Paul (Jira)]

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

Noble Paul resolved SOLR-14151.
---
Resolution: Fixed

> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Labels: packagemanager
> Fix For: 8.7
>
>  Time Spent: 12h 40m
>  Remaining Estimate: 0h
>
> Example:
> {code:xml}
>  
> 
>   
>generateNumberParts="0" catenateWords="0"
>   catenateNumbers="0" catenateAll="0"/>
>   
>   
> 
>   
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed, 
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components 
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API



--
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-9497) Integerate Error Prone ( Static Analysis Tool ) during compilation

[ASF subversion and git services (Jira)]

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

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

Commit f7cbde2ad85b656b7c7ac16acaafb05481fa75ba in lucene-solr's branch 
refs/heads/master from Varun Thacker
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f7cbde2 ]

Update CHANGES.txt

LUCENE-9497 is only for master ( since it's a gradle plugin )

> Integerate Error Prone ( Static Analysis Tool ) during compilation
> --
>
> Key: LUCENE-9497
> URL: https://issues.apache.org/jira/browse/LUCENE-9497
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Varun Thacker
>Priority: Minor
>  Time Spent: 5h 10m
>  Remaining Estimate: 0h
>
> Integrate [https://github.com/google/error-prone] during compilation of our 
> source code to catch mistakes



--
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-14842) Address Tolerant search feature and tests.

[Mark Robert Miller (Jira)]

Mark Robert Miller created SOLR-14842:
-

 Summary: Address Tolerant search feature and tests.
 Key: SOLR-14842
 URL: https://issues.apache.org/jira/browse/SOLR-14842
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mark Robert Miller


I think this stuff is off now because of doing distrib updates local/dist in 
parallel and perhaps the change to using the http2 client with async for 
distributing updates and capturing errors (proper errors finally, not the 
concurrent client mess). Likely needs some little tweaks.



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

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

[GitHub] [lucene-solr] dweiss commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

dweiss commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688642607


   bq.  32s before, 24s with this PR 
   
   Well, that's 25% faster. The biggest gain should come from running 
incrementally? If you modify a file in just one of the projects, only that 
project's task should be re-run.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] dweiss commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

dweiss commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r484674873



##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -29,50 +33,127 @@ buildscript {
   }
 }
 
-configure(rootProject) {
-  task("validateSourcePatterns", type: ValidateSourcePatternsTask) { task ->
+def extensions = [
+'adoc',
+'bat',
+'cmd',
+'css',
+'g4',
+'gradle',
+'groovy',
+'html',
+'java',
+'jflex',
+'jj',
+'js',
+'json',
+'md',
+'mdtext',
+'pl',
+'policy',
+'properties',
+'py',
+'sh',
+'template',
+'vm',
+'xml',
+'xsl',
+]
+
+// Create source validation task local for each project's files.
+subprojects {
+  task validateSourcePatterns(type: ValidateSourcePatternsTask) { task ->
 group = 'Verification'
 description = 'Validate Source Patterns'
 
 // This task has no proper outputs.
 setupDummyOutputs(task)
 
-sourceFiles = project.fileTree(project.rootDir) {
-  [
-'java', 'jflex', 'py', 'pl', 'g4', 'jj', 'html', 'js',
-'css', 'xml', 'xsl', 'vm', 'sh', 'cmd', 'bat', 'policy',
-'properties', 'mdtext', 'groovy', 'gradle',
-'template', 'adoc', 'json',
-  ].each{
-include "lucene/**/*.${it}"
-include "solr/**/*.${it}"
-include "dev-tools/**/*.${it}"
-include "gradle/**/*.${it}"
-include "*.${it}"
+sourceFiles = fileTree(projectDir) {
+  extensions.each{
+include "**/*.${it}"
   }
-  // TODO: For now we don't scan txt / md files, so we
-  // check licenses in top-level folders separately:
-  include '*.txt'
-  include '*/*.txt'
-  include '*.md'
-  include '*/*.md'
-  // excludes:
+  
+  // Don't go into child projects (scanned separately).

Review comment:
   Yep, that should do it.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] noblepaul commented on pull request #1831: SOLR-14749 the scheduler part

[GitBox]

noblepaul commented on pull request #1831:
URL: https://github.com/apache/lucene-solr/pull/1831#issuecomment-688645297


   Can we just commit the `ClusterSingleton` as one PR please? `Scheduler` and 
`ClusterSingleton` doesn't have to go in together



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] dweiss commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

dweiss commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r484678759



##
File path: gradle/validation/precommit.gradle
##
@@ -26,7 +26,6 @@ configure(rootProject) {
 dependsOn ":verifyLocks"
 dependsOn ":versionsPropsAreSorted"
 dependsOn ":checkWorkingCopyClean"
-dependsOn ":validateSourcePatterns"

Review comment:
   I think we can leave the dependency on the root task as it depends on 
other source pattern validations. Or remove the snippet that connects them 
later.

##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -29,50 +33,127 @@ buildscript {
   }
 }
 
-configure(rootProject) {
-  task("validateSourcePatterns", type: ValidateSourcePatternsTask) { task ->
+def extensions = [
+'adoc',
+'bat',
+'cmd',
+'css',
+'g4',
+'gradle',
+'groovy',
+'html',
+'java',
+'jflex',
+'jj',
+'js',
+'json',
+'md',
+'mdtext',
+'pl',
+'policy',
+'properties',
+'py',
+'sh',
+'template',
+'vm',
+'xml',
+'xsl',
+]
+
+// Create source validation task local for each project's files.
+subprojects {
+  task validateSourcePatterns(type: ValidateSourcePatternsTask) { task ->
 group = 'Verification'
 description = 'Validate Source Patterns'
 
 // This task has no proper outputs.
 setupDummyOutputs(task)
 
-sourceFiles = project.fileTree(project.rootDir) {
-  [
-'java', 'jflex', 'py', 'pl', 'g4', 'jj', 'html', 'js',
-'css', 'xml', 'xsl', 'vm', 'sh', 'cmd', 'bat', 'policy',
-'properties', 'mdtext', 'groovy', 'gradle',
-'template', 'adoc', 'json',
-  ].each{
-include "lucene/**/*.${it}"
-include "solr/**/*.${it}"
-include "dev-tools/**/*.${it}"
-include "gradle/**/*.${it}"
-include "*.${it}"
+sourceFiles = fileTree(projectDir) {
+  extensions.each{
+include "**/*.${it}"
   }
-  // TODO: For now we don't scan txt / md files, so we
-  // check licenses in top-level folders separately:
-  include '*.txt'
-  include '*/*.txt'
-  include '*.md'
-  include '*/*.md'
-  // excludes:
+  
+  // Don't go into child projects (scanned separately).
+  childProjects.keySet().each{
+exclude "${it}/**"
+  }
+
+  // default excludes.
+  exclude 'build/**'
+}
+  }
+
+  // Add source validation to per-project checks as well.
+  check.dependsOn validateSourcePatterns
+}
+
+configure(project(':lucene:benchmark')) {
+  project.tasks.withType(ValidateSourcePatternsTask) {
+sourceFiles.exclude 'temp/**'
+sourceFiles.exclude 'work/**'
+  }
+}
+
+configure(project(':solr:core')) {
+  project.tasks.withType(ValidateSourcePatternsTask) {
+sourceFiles.exclude 'src/**/CheckLoggingConfiguration.java'
+sourceFiles.exclude 'src/test/org/apache/hadoop/**'
+  }
+}
+
+configure(rootProject) {
+  task validateRootAndOtherFiles(type: ValidateSourcePatternsTask) { task ->
+// This task has no proper outputs.
+setupDummyOutputs(task)
+
+sourceFiles = fileTree(projectDir) {
+  extensions.each{
+include "**/*.${it}"
+  }
+
+  // We do not scan for *.txt by default (broken files in subprojects),
+  // but in root we can do this).
+  include '**/*.txt'
+
+  // Don't go into child projects (scanned separately).
+  childProjects.keySet().each{
+exclude "${it}/**"
+  }
+
+  // default excludes.
   exclude '**/build/**'
-  exclude '**/dist/**'
   exclude 'dev-tools/missing-doclet/src/**/*.java' // <-- TODO: remove 
once we allow "var" on master
-  exclude 'lucene/benchmark/work/**'
-  exclude 'lucene/benchmark/temp/**'
-  exclude '**/CheckLoggingConfiguration.java'
-  exclude 'solr/core/src/test/org/apache/hadoop/**'
-  exclude '**/validate-source-patterns.gradle' // ourselves :-)
+
+  // ourselves :-)
+  exclude 'gradle/validation/validate-source-patterns.gradle'
 }
   }
+
+  task validateSourcePatterns() {
+group = 'Verification'
+description = 'Validate Source Patterns'
+
+// Make it depend on all so-named tasks from subprojects.

Review comment:
   (here).





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] sigram edited a comment on pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.

[GitBox]

sigram edited a comment on pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#issuecomment-688426745


   FWIW, the scheduler part is now in PR #1831.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1813: SOLR-14613: No new APIs. use the existing APIs

[GitBox]

noblepaul commented on a change in pull request #1813:
URL: https://github.com/apache/lucene-solr/pull/1813#discussion_r484682298



##
File path: solr/core/src/java/org/apache/solr/cloud/api/collections/Assign.java
##
@@ -551,11 +555,29 @@ public AssignStrategyFactory(SolrCloudManager 
solrCloudManager) {
   this.solrCloudManager = solrCloudManager;
 }
 
+@SuppressWarnings("unchecked")
 public AssignStrategy create(ClusterState clusterState, CloudConfig 
cloudConfig, DocCollection collection) throws IOException, InterruptedException 
{
   @SuppressWarnings({"unchecked", "rawtypes"})
   List ruleMaps = (List) collection.get("rule");
   @SuppressWarnings({"rawtypes"})
   List snitches = (List) collection.get(SNITCH);
+  Map props = 
solrCloudManager.getClusterStateProvider().getClusterProperties();
+  Map assignInfo = (Map) 
props.get("assign-strategy");

Review comment:
   We already have an endpoint called  `/api/cluster/plugin`  GET/POST
   
   Please refer to 
[SOLR-14404](https://issues.apache.org/jira/browse/SOLR-14404) for details
   
   it can look as follows
   
   ```
   curl -X POST -H 'Content-type:application/json' --data-binary '
   {
 "set-assign-strategy": {
 "class": "full.ClassName", 
 "key1" : "val1"
 }
   }' http://localhost:8983/api/cluster/plugins
   ```





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] dweiss commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

dweiss commented on pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-688650077


   I have a suspicion those filetree filters (exclusion filters) are fairly 
dumb and scan paths that can't be traversed anyway. I'd have to confirm to be 
sure (which I can't do now). Anyway, I think it's better than before anyway, so 
let's leave it for later improvements, if necessary.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1813: SOLR-14613: No new APIs. use the existing APIs

[GitBox]

noblepaul commented on a change in pull request #1813:
URL: https://github.com/apache/lucene-solr/pull/1813#discussion_r484682298



##
File path: solr/core/src/java/org/apache/solr/cloud/api/collections/Assign.java
##
@@ -551,11 +555,29 @@ public AssignStrategyFactory(SolrCloudManager 
solrCloudManager) {
   this.solrCloudManager = solrCloudManager;
 }
 
+@SuppressWarnings("unchecked")
 public AssignStrategy create(ClusterState clusterState, CloudConfig 
cloudConfig, DocCollection collection) throws IOException, InterruptedException 
{
   @SuppressWarnings({"unchecked", "rawtypes"})
   List ruleMaps = (List) collection.get("rule");
   @SuppressWarnings({"rawtypes"})
   List snitches = (List) collection.get(SNITCH);
+  Map props = 
solrCloudManager.getClusterStateProvider().getClusterProperties();
+  Map assignInfo = (Map) 
props.get("assign-strategy");

Review comment:
   We already have an endpoint called  `/api/cluster/plugin`  GET/POST
   
   Please refer to 
[SOLR-14404](https://issues.apache.org/jira/browse/SOLR-14404) for details
   
   it can look as follows
   
   ```
   curl -X POST -H 'Content-type:application/json' --data-binary '
   {
 "set-assign-strategy": {
 "class": "full.ClassName", 
 "key1" : "val1"
 }
   }' http://localhost:8983/api/cluster/plugins
   ```
   
   You may add your code 
[here](https://github.com/apache/lucene-solr/blob/f7cbde2ad85b656b7c7ac16acaafb05481fa75ba/solr/core/src/java/org/apache/solr/handler/admin/ContainerPluginsApi.java#L77)
   
   





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1813: SOLR-14613: No new APIs. use the existing APIs

[GitBox]

noblepaul commented on a change in pull request #1813:
URL: https://github.com/apache/lucene-solr/pull/1813#discussion_r484682298



##
File path: solr/core/src/java/org/apache/solr/cloud/api/collections/Assign.java
##
@@ -551,11 +555,29 @@ public AssignStrategyFactory(SolrCloudManager 
solrCloudManager) {
   this.solrCloudManager = solrCloudManager;
 }
 
+@SuppressWarnings("unchecked")
 public AssignStrategy create(ClusterState clusterState, CloudConfig 
cloudConfig, DocCollection collection) throws IOException, InterruptedException 
{
   @SuppressWarnings({"unchecked", "rawtypes"})
   List ruleMaps = (List) collection.get("rule");
   @SuppressWarnings({"rawtypes"})
   List snitches = (List) collection.get(SNITCH);
+  Map props = 
solrCloudManager.getClusterStateProvider().getClusterProperties();
+  Map assignInfo = (Map) 
props.get("assign-strategy");

Review comment:
   We already have an endpoint called  `/api/cluster/plugin`  GET/POST
   
   Please refer to 
[SOLR-14404](https://issues.apache.org/jira/browse/SOLR-14404) for details
   
   it can look as follows
   
   ```
   curl -X POST -H 'Content-type:application/json' --data-binary '
   {
 "set-assign-strategy": {
 "class": "full.ClassName", 
 "key1" : "val1"
 }
   }' http://localhost:8983/api/cluster/plugins
   ```
   ```
   curl -X POST -H 'Content-type:application/json' --data-binary '
   {
 "set-assign-strategy":  null
   }' http://localhost:8983/api/cluster/plugins
   ```
   You may add your code 
[here](https://github.com/apache/lucene-solr/blob/f7cbde2ad85b656b7c7ac16acaafb05481fa75ba/solr/core/src/java/org/apache/solr/handler/admin/ContainerPluginsApi.java#L77)
   
   





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r484690577



##
File path: gradle/validation/precommit.gradle
##
@@ -26,7 +26,6 @@ configure(rootProject) {
 dependsOn ":verifyLocks"
 dependsOn ":versionsPropsAreSorted"
 dependsOn ":checkWorkingCopyClean"
-dependsOn ":validateSourcePatterns"

Review comment:
   I wanted to make it consistent with the others. Now all are handled the 
same.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r484691201



##
File path: gradle/validation/precommit.gradle
##
@@ -26,7 +26,6 @@ configure(rootProject) {
 dependsOn ":verifyLocks"
 dependsOn ":versionsPropsAreSorted"
 dependsOn ":checkWorkingCopyClean"
-dependsOn ":validateSourcePatterns"

Review comment:
   Removing the connection in subprojects is not good, as now I can run 
`gradlew check` in a subproject and it does everything right.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] dweiss commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

dweiss commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r484691497



##
File path: gradle/validation/precommit.gradle
##
@@ -26,7 +26,6 @@ configure(rootProject) {
 dependsOn ":verifyLocks"
 dependsOn ":versionsPropsAreSorted"
 dependsOn ":checkWorkingCopyClean"
-dependsOn ":validateSourcePatterns"

Review comment:
   Fair enough. But then the top-level one doesn't need to depend on 
children?





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] uschindler commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

uschindler commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r484692069



##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -29,50 +33,127 @@ buildscript {
   }
 }
 
-configure(rootProject) {
-  task("validateSourcePatterns", type: ValidateSourcePatternsTask) { task ->
+def extensions = [
+'adoc',
+'bat',
+'cmd',
+'css',
+'g4',
+'gradle',
+'groovy',
+'html',
+'java',
+'jflex',
+'jj',
+'js',
+'json',
+'md',
+'mdtext',
+'pl',
+'policy',
+'properties',
+'py',
+'sh',
+'template',
+'vm',
+'xml',
+'xsl',
+]
+
+// Create source validation task local for each project's files.
+subprojects {
+  task validateSourcePatterns(type: ValidateSourcePatternsTask) { task ->
 group = 'Verification'
 description = 'Validate Source Patterns'
 
 // This task has no proper outputs.
 setupDummyOutputs(task)
 
-sourceFiles = project.fileTree(project.rootDir) {
-  [
-'java', 'jflex', 'py', 'pl', 'g4', 'jj', 'html', 'js',
-'css', 'xml', 'xsl', 'vm', 'sh', 'cmd', 'bat', 'policy',
-'properties', 'mdtext', 'groovy', 'gradle',
-'template', 'adoc', 'json',
-  ].each{
-include "lucene/**/*.${it}"
-include "solr/**/*.${it}"
-include "dev-tools/**/*.${it}"
-include "gradle/**/*.${it}"
-include "*.${it}"
+sourceFiles = fileTree(projectDir) {
+  extensions.each{
+include "**/*.${it}"
   }
-  // TODO: For now we don't scan txt / md files, so we
-  // check licenses in top-level folders separately:
-  include '*.txt'
-  include '*/*.txt'
-  include '*.md'
-  include '*/*.md'
-  // excludes:
+  
+  // Don't go into child projects (scanned separately).
+  childProjects.keySet().each{
+exclude "${it}/**"
+  }
+
+  // default excludes.
+  exclude 'build/**'
+}
+  }
+
+  // Add source validation to per-project checks as well.
+  check.dependsOn validateSourcePatterns
+}
+
+configure(project(':lucene:benchmark')) {
+  project.tasks.withType(ValidateSourcePatternsTask) {
+sourceFiles.exclude 'temp/**'
+sourceFiles.exclude 'work/**'
+  }
+}
+
+configure(project(':solr:core')) {
+  project.tasks.withType(ValidateSourcePatternsTask) {
+sourceFiles.exclude 'src/**/CheckLoggingConfiguration.java'
+sourceFiles.exclude 'src/test/org/apache/hadoop/**'
+  }
+}
+
+configure(rootProject) {
+  task validateRootAndOtherFiles(type: ValidateSourcePatternsTask) { task ->
+// This task has no proper outputs.
+setupDummyOutputs(task)
+
+sourceFiles = fileTree(projectDir) {
+  extensions.each{
+include "**/*.${it}"
+  }
+
+  // We do not scan for *.txt by default (broken files in subprojects),
+  // but in root we can do this).
+  include '**/*.txt'
+
+  // Don't go into child projects (scanned separately).
+  childProjects.keySet().each{
+exclude "${it}/**"
+  }
+
+  // default excludes.
   exclude '**/build/**'
-  exclude '**/dist/**'
   exclude 'dev-tools/missing-doclet/src/**/*.java' // <-- TODO: remove 
once we allow "var" on master
-  exclude 'lucene/benchmark/work/**'
-  exclude 'lucene/benchmark/temp/**'
-  exclude '**/CheckLoggingConfiguration.java'
-  exclude 'solr/core/src/test/org/apache/hadoop/**'
-  exclude '**/validate-source-patterns.gradle' // ourselves :-)
+
+  // ourselves :-)
+  exclude 'gradle/validation/validate-source-patterns.gradle'
 }
   }
+
+  task validateSourcePatterns() {
+group = 'Verification'
+description = 'Validate Source Patterns'
+
+// Make it depend on all so-named tasks from subprojects.

Review comment:
   I also want this to be able to run it from root separately. If that's 
not needed and works automatically, remove it here.
   
   I just made it consistent with other validation tasks 





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] dweiss commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…

[GitBox]

dweiss commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r484691998



##
File path: gradle/validation/precommit.gradle
##
@@ -26,7 +26,6 @@ configure(rootProject) {
 dependsOn ":verifyLocks"
 dependsOn ":versionsPropsAreSorted"
 dependsOn ":checkWorkingCopyClean"
-dependsOn ":validateSourcePatterns"

Review comment:
   Ah, ok. See it now.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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