[jira] [Commented] (LUCENE-9552) Add a LatLonPoint query that accepts an array of LatLonGeometries
[ https://issues.apache.org/jira/browse/LUCENE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225216#comment-17225216 ] ASF subversion and git services commented on LUCENE-9552: - Commit 8bfbed8d4cd476a008ee85310b1f6535920b4622 in lucene-solr's branch refs/heads/master from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8bfbed8 ] LUCENE-9552: Adds a LatLonPoint query that accepts an array of LatLonGeometries (#1940) > Add a LatLonPoint query that accepts an array of LatLonGeometries > - > > Key: LUCENE-9552 > URL: https://issues.apache.org/jira/browse/LUCENE-9552 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > LatLonPoint currently support three types of queries, against a bound box, an > array of polygons or by distance (circle). Therefore if you currently want to > combine a query with two of those geometries, a user will need to combine the > query with a boolean OR. > It would be a nice addition to have a query that accepts an array of > LatLonGeometries and generates that boolean OR query in a single query. -- 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-9552) Add a LatLonPoint query that accepts an array of LatLonGeometries
[ https://issues.apache.org/jira/browse/LUCENE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225215#comment-17225215 ] ASF subversion and git services commented on LUCENE-9552: - Commit 8bfbed8d4cd476a008ee85310b1f6535920b4622 in lucene-solr's branch refs/heads/master from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8bfbed8 ] LUCENE-9552: Adds a LatLonPoint query that accepts an array of LatLonGeometries (#1940) > Add a LatLonPoint query that accepts an array of LatLonGeometries > - > > Key: LUCENE-9552 > URL: https://issues.apache.org/jira/browse/LUCENE-9552 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > LatLonPoint currently support three types of queries, against a bound box, an > array of polygons or by distance (circle). Therefore if you currently want to > combine a query with two of those geometries, a user will need to combine the > query with a boolean OR. > It would be a nice addition to have a query that accepts an array of > LatLonGeometries and generates that boolean OR query in a single query. -- 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-9552) Add a LatLonPoint query that accepts an array of LatLonGeometries
[ https://issues.apache.org/jira/browse/LUCENE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225217#comment-17225217 ] ASF subversion and git services commented on LUCENE-9552: - Commit 8bfbed8d4cd476a008ee85310b1f6535920b4622 in lucene-solr's branch refs/heads/master from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8bfbed8 ] LUCENE-9552: Adds a LatLonPoint query that accepts an array of LatLonGeometries (#1940) > Add a LatLonPoint query that accepts an array of LatLonGeometries > - > > Key: LUCENE-9552 > URL: https://issues.apache.org/jira/browse/LUCENE-9552 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > LatLonPoint currently support three types of queries, against a bound box, an > array of polygons or by distance (circle). Therefore if you currently want to > combine a query with two of those geometries, a user will need to combine the > query with a boolean OR. > It would be a nice addition to have a query that accepts an array of > LatLonGeometries and generates that boolean OR query in a single query. -- 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-9552) Add a LatLonPoint query that accepts an array of LatLonGeometries
[ https://issues.apache.org/jira/browse/LUCENE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225220#comment-17225220 ] ASF subversion and git services commented on LUCENE-9552: - Commit e30959f8cab9d56dfcbb8cd41efb64cba3714d3b in lucene-solr's branch refs/heads/branch_8x from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e30959f ] LUCENE-9552: Adds a LatLonPoint query that accepts an array of LatLonGeometries (#1940) > Add a LatLonPoint query that accepts an array of LatLonGeometries > - > > Key: LUCENE-9552 > URL: https://issues.apache.org/jira/browse/LUCENE-9552 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > LatLonPoint currently support three types of queries, against a bound box, an > array of polygons or by distance (circle). Therefore if you currently want to > combine a query with two of those geometries, a user will need to combine the > query with a boolean OR. > It would be a nice addition to have a query that accepts an array of > LatLonGeometries and generates that boolean OR query in a single query. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9552) Add a LatLonPoint query that accepts an array of LatLonGeometries
[ https://issues.apache.org/jira/browse/LUCENE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera resolved LUCENE-9552. -- Fix Version/s: 8.8 Assignee: Ignacio Vera Resolution: Fixed > Add a LatLonPoint query that accepts an array of LatLonGeometries > - > > Key: LUCENE-9552 > URL: https://issues.apache.org/jira/browse/LUCENE-9552 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Assignee: Ignacio Vera >Priority: Major > Fix For: 8.8 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > LatLonPoint currently support three types of queries, against a bound box, an > array of polygons or by distance (circle). Therefore if you currently want to > combine a query with two of those geometries, a user will need to combine the > query with a boolean OR. > It would be a nice addition to have a query that accepts an array of > LatLonGeometries and generates that boolean OR query in a single query. -- 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-9553) Add a XYPoint query that accepts an array of XYGeometries
[ https://issues.apache.org/jira/browse/LUCENE-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225227#comment-17225227 ] ASF subversion and git services commented on LUCENE-9553: - Commit 5c0273791865109be8495ecec385aeedf043bc89 in lucene-solr's branch refs/heads/master from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5c02737 ] LUCENE-9553: Adds a XYPoint query that accepts an array of XYGeometries (#1939) > Add a XYPoint query that accepts an array of XYGeometries > - > > Key: LUCENE-9553 > URL: https://issues.apache.org/jira/browse/LUCENE-9553 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Priority: Major > > Similar to LUCENE-9553, it would be nice to have a query accepts an array of > LatLonGeometries. -- 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-9553) Add a XYPoint query that accepts an array of XYGeometries
[ https://issues.apache.org/jira/browse/LUCENE-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225228#comment-17225228 ] ASF subversion and git services commented on LUCENE-9553: - Commit ed80f996e67d0a80e55e0815b783b19ef53e9988 in lucene-solr's branch refs/heads/branch_8x from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ed80f99 ] LUCENE-9553: Adds a XYPoint query that accepts an array of XYGeometries (#1939) > Add a XYPoint query that accepts an array of XYGeometries > - > > Key: LUCENE-9553 > URL: https://issues.apache.org/jira/browse/LUCENE-9553 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Priority: Major > > Similar to LUCENE-9553, it would be nice to have a query accepts an array of > LatLonGeometries. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9553) Add a XYPoint query that accepts an array of XYGeometries
[ https://issues.apache.org/jira/browse/LUCENE-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera resolved LUCENE-9553. -- Fix Version/s: 8.8 Assignee: Ignacio Vera Resolution: Fixed > Add a XYPoint query that accepts an array of XYGeometries > - > > Key: LUCENE-9553 > URL: https://issues.apache.org/jira/browse/LUCENE-9553 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Assignee: Ignacio Vera >Priority: Major > Fix For: 8.8 > > > Similar to LUCENE-9553, it would be nice to have a query accepts an array of > LatLonGeometries. -- 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-14926) Modernize and clean up document clustering contrib
[ https://issues.apache.org/jira/browse/SOLR-14926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225234#comment-17225234 ] ASF subversion and git services commented on SOLR-14926: Commit 0f871b2c560d92cb5cc481f34d1f1bc576e8e582 in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0f871b2 ] SOLR-14926: Modernize and clean up search results clustering contrib. > Modernize and clean up document clustering contrib > -- > > Key: SOLR-14926 > URL: https://issues.apache.org/jira/browse/SOLR-14926 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > > The clustering contrib was written a long time ago and it shows its age. We > have two separate interfaces (for clustering search results and for > clustering documents). The second one never received any attention and no > implementation exists for it. > I plan to do the following: > - *remove* the document clustering interface entirely, leave only the > post-search results clustering extension, > - upgrade the implementation to Carrot2 4.x (this gets rid of those > long-standing odd dependencies), > - clean up the code where appropriate. > My plan is to apply this to master, initially, but also backport to 8x if > there are no objections. I don't think it'll hurt anybody. -- 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-14981) Remove search results clustering contrib from 8x
Dawid Weiss created SOLR-14981: -- Summary: Remove search results clustering contrib from 8x Key: SOLR-14981 URL: https://issues.apache.org/jira/browse/SOLR-14981 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Dawid Weiss Assignee: Dawid Weiss -- 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-14981) Remove search results clustering contrib from 8x
[ https://issues.apache.org/jira/browse/SOLR-14981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-14981: --- Description: Up-to-date Carrot2 clustering library requires Java 11+. This makes it impossible to maintain the search results clustering extension on Solr 8.x. This issue removes the contrib entirely. A backport of master-only patch that modernizes and cleans up the clustering contrib is available as a patch at SOLR-14974. > Remove search results clustering contrib from 8x > > > Key: SOLR-14981 > URL: https://issues.apache.org/jira/browse/SOLR-14981 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > > Up-to-date Carrot2 clustering library requires Java 11+. This makes it > impossible to maintain the search results clustering extension on Solr 8.x. > This issue removes the contrib entirely. > A backport of master-only patch that modernizes and cleans up the clustering > contrib is available as a patch at SOLR-14974. -- 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-9595) Component2D#withinPoint logic is inconsistent with ShapeQuery logic
Ignacio Vera created LUCENE-9595: Summary: Component2D#withinPoint logic is inconsistent with ShapeQuery logic Key: LUCENE-9595 URL: https://issues.apache.org/jira/browse/LUCENE-9595 Project: Lucene - Core Issue Type: Bug Reporter: Ignacio Vera The logic of ShapeQuery for contains assumes that if a branch of the BKD tree is inside of the shape query, the all documents in that branch are excluded from the result. On the other hand, Component2D#withinPoint implementation, eg. Polygon2D, ignores points even when the point is inside the query. That might lead to inconsistencies in edges cases with geometry collections. The proposal here is to keep the logic of the shapeQuery and therefore contains logic will only return true if the query shape is inside a geometry and it does not intersects with any other geometry belonging to the same document. -- 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-9596) Reproduce line for failed tests should have method-level accuracy
Dawid Weiss created LUCENE-9596: --- Summary: Reproduce line for failed tests should have method-level accuracy Key: LUCENE-9596 URL: https://issues.apache.org/jira/browse/LUCENE-9596 Project: Lucene - Core Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Currently the entire class is re-run in repro line; we can instruct gradle to rerun just a the failing test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9596) Reproduce line for failed tests should have method-level accuracy
[ https://issues.apache.org/jira/browse/LUCENE-9596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-9596. - Fix Version/s: master (9.0) Resolution: Fixed > Reproduce line for failed tests should have method-level accuracy > - > > Key: LUCENE-9596 > URL: https://issues.apache.org/jira/browse/LUCENE-9596 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > > Currently the entire class is re-run in repro line; we can instruct gradle to > rerun just a the failing test. -- 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-9596) Reproduce line for failed tests should have method-level accuracy
[ https://issues.apache.org/jira/browse/LUCENE-9596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225275#comment-17225275 ] ASF subversion and git services commented on LUCENE-9596: - Commit 63c4dfa454414a18e03c7d6d6672c0540c026a33 in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=63c4dfa ] LUCENE-9596: Reproduce line for failed tests should have method-level accuracy > Reproduce line for failed tests should have method-level accuracy > - > > Key: LUCENE-9596 > URL: https://issues.apache.org/jira/browse/LUCENE-9596 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > > Currently the entire class is re-run in repro line; we can instruct gradle to > rerun just a the failing test. -- 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-14926) Modernize and clean up document clustering contrib
[ https://issues.apache.org/jira/browse/SOLR-14926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-14926. Resolution: Fixed > Modernize and clean up document clustering contrib > -- > > Key: SOLR-14926 > URL: https://issues.apache.org/jira/browse/SOLR-14926 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > > The clustering contrib was written a long time ago and it shows its age. We > have two separate interfaces (for clustering search results and for > clustering documents). The second one never received any attention and no > implementation exists for it. > I plan to do the following: > - *remove* the document clustering interface entirely, leave only the > post-search results clustering extension, > - upgrade the implementation to Carrot2 4.x (this gets rid of those > long-standing odd dependencies), > - clean up the code where appropriate. > My plan is to apply this to master, initially, but also backport to 8x if > there are no objections. I don't think it'll hurt anybody. -- 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-14982) I don't understand method toQueryString of SolrParams.
Warren Wen created SOLR-14982: - Summary: I don't understand method toQueryString of SolrParams. Key: SOLR-14982 URL: https://issues.apache.org/jira/browse/SOLR-14982 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 8.6.1 Reporter: Warren Wen I query string is " test. ". I except it query in solr is " test. " also. But in *toQueryString(),* it use URLEncoder.encode to decode query string, It will be change " " to "", and solr server throw a error to me. Why use , not "%20" to replace " "(space)? If use "%20" to replace " ", it will be ok in solr. It is a bug? -- 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-14981) Remove search results clustering contrib from 8x
[ https://issues.apache.org/jira/browse/SOLR-14981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225286#comment-17225286 ] ASF subversion and git services commented on SOLR-14981: Commit e334ba104a4a97fa59e5c5175ee97aa85adffe8d in lucene-solr's branch refs/heads/branch_8x from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e334ba1 ] SOLR-14981: Remove search results clustering contrib from 8x (#2058) > Remove search results clustering contrib from 8x > > > Key: SOLR-14981 > URL: https://issues.apache.org/jira/browse/SOLR-14981 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > > Up-to-date Carrot2 clustering library requires Java 11+. This makes it > impossible to maintain the search results clustering extension on Solr 8.x. > This issue removes the contrib entirely. > A backport of master-only patch that modernizes and cleans up the clustering > contrib is available as a patch at SOLR-14974. -- 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-14981) Remove search results clustering contrib from 8x
[ https://issues.apache.org/jira/browse/SOLR-14981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-14981. Fix Version/s: 8.8 Resolution: Fixed > Remove search results clustering contrib from 8x > > > Key: SOLR-14981 > URL: https://issues.apache.org/jira/browse/SOLR-14981 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 8.8 > > > Up-to-date Carrot2 clustering library requires Java 11+. This makes it > impossible to maintain the search results clustering extension on Solr 8.x. > This issue removes the contrib entirely. > A backport of master-only patch that modernizes and cleans up the clustering > contrib is available as a patch at SOLR-14974. -- 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-14837) prometheus-exporter: different metrics ports publishes mixed metrics
[ https://issues.apache.org/jira/browse/SOLR-14837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225294#comment-17225294 ] Jan Høydahl commented on SOLR-14837: Thanks, looks good. Normally we name the patch SOLR-XXX.patch. See [https://cwiki.apache.org/confluence/display/solr/HowToContribute] for more hints on how to contribute. > 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 > Components: contrib - prometheus-exporter >Affects Versions: 8.6.2 >Reporter: Fadi Mohsen >Priority: Minor > Attachments: patch.log > > > 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
[ https://issues.apache.org/jira/browse/SOLR-14837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-14837: --- Status: Patch Available (was: Open) > 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 > Components: contrib - prometheus-exporter >Affects Versions: 8.6.2 >Reporter: Fadi Mohsen >Priority: Minor > Attachments: patch.log > > > 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-14912) Unify solr-contrib-extraction with the artifact it produces (solr-cell)
[
https://issues.apache.org/jira/browse/SOLR-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated SOLR-14912:
---
Description:
This is similar to Lucene analysis/analyzers inconsistency. The
'solr/contrib/extraction' produces 'solr-contrib-cell' artifact. I suggest we
should make it consistent and simpler by just producing
'solr-contrib-extraction' instead.
{code}
// This project has a different artifact name (solr-contrib-cell). Don't know
why.
configure(project(":solr:contrib:extraction")) {
archivesBaseName = "solr-cell"
}
{code}
https://github.com/apache/lucene-solr/pull/2060/files
was:
This is similar to Lucene analysis/analyzers inconsistency. The
'solr/contrib/extraction' produces 'solr-contrib-cell' artifact. I suggest we
should make it consistent and simpler by just producing
'solr-contrib-extraction' instead.
{code}
// This project has a different artifact name (solr-contrib-cell). Don't know
why.
configure(project(":solr:contrib:extraction")) {
archivesBaseName = "solr-cell"
}
{code}
> Unify solr-contrib-extraction with the artifact it produces (solr-cell)
> ---
>
> Key: SOLR-14912
> URL: https://issues.apache.org/jira/browse/SOLR-14912
> Project: Solr
> Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
>
> This is similar to Lucene analysis/analyzers inconsistency. The
> 'solr/contrib/extraction' produces 'solr-contrib-cell' artifact. I suggest we
> should make it consistent and simpler by just producing
> 'solr-contrib-extraction' instead.
> {code}
> // This project has a different artifact name (solr-contrib-cell). Don't know
> why.
> configure(project(":solr:contrib:extraction")) {
> archivesBaseName = "solr-cell"
> }
> {code}
> https://github.com/apache/lucene-solr/pull/2060/files
--
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-9597) checkWorkingCopyClean shouldn't complain about untracked empty folders (similar to git status)
Dawid Weiss created LUCENE-9597: --- Summary: checkWorkingCopyClean shouldn't complain about untracked empty folders (similar to git status) Key: LUCENE-9597 URL: https://issues.apache.org/jira/browse/LUCENE-9597 Project: Lucene - Core Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss -- 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-9597) checkWorkingCopyClean shouldn't complain about untracked empty folders (similar to git status)
[ https://issues.apache.org/jira/browse/LUCENE-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-9597: Description: https://github.com/apache/lucene-solr/pull/2061 > checkWorkingCopyClean shouldn't complain about untracked empty folders > (similar to git status) > -- > > Key: LUCENE-9597 > URL: https://issues.apache.org/jira/browse/LUCENE-9597 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > > https://github.com/apache/lucene-solr/pull/2061 -- 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-10202) Auto resolve urlScheme, remove cluster property
[
https://issues.apache.org/jira/browse/SOLR-10202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225318#comment-17225318
]
Jan Høydahl commented on SOLR-10202:
In SOLR-12182 the scheme is parameterized in state.json which takes us one step
closer to a smoother switch between schemes. Tim mentioned this issue and
rightly pointed out that a {{CloudSolrClient}} external from the cluster also
needs to know urlScheme, which it gets from ZK today.
This made me thinking. Can we simply add a new {{.withUrlScheme()}} method to
{{CloudSolrClient.Builder}}? It won't be back compat, but it will give clients
a way to provide the scheme. Could alternatively provide a
{{UrlSchemeResolver}} interface. Implementations could be
{{StaticUrlSchemeResolver, ZkUrlSchemeResolver, SysPropUrlSchemeResolver or
SniffUrlSchemeResolver}}, where the OOTB could be the sysprop one, and the
Sniff* one would attempt both and use the one that returns a valid response :)
> Auto resolve urlScheme, remove cluster property
> ---
>
> Key: SOLR-10202
> URL: https://issues.apache.org/jira/browse/SOLR-10202
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Reporter: Jan Høydahl
>Assignee: Timothy Potter
>Priority: Major
>
> Spinoff from SOLR-9640.
> Today we need to explicitly set {{urlScheme}} cluster property to enable SSL,
> at the same time as we need to set all the SSL env variables on each node. As
> discussed in SOLR-9640, we could be smarter about this so an admin only need
> to setup {{solr.in.sh}} with keystore to enable SSL.
> h3. How
> Perhaps simplified a bit, but in principle, at node start, if
> {{solr.jetty.keystore}} (one out of several possiilities) is defined then use
> https, else http :-) Then, if the administrator has mixed it up and failed to
> configure {{solr.jetty.keystore}} on one of the nodes, then that node will
> not be able to communicate with the others over {{http}}, it will get {{curl:
> (52) Empty reply from server}}. Opposite, an SSL enabled node trying to talk
> to a Solr node that is not SSL enabled over {{https}}, will get {{curl: (35)
> Unknown SSL protocol error in connection to localhost:-9847}} (not the curl
> error of course, but similar).
> I don't think the nodes need to tell ZK about SSL at all?
> So my claim is that this will not give bigger risk of misconfiguration, cause
> if you add a new node to the cluster without SSL, it will generate a lot of
> BUZZ in the logs and it will never receive any unencrypted data from the
> other nodes since connections will fail. Agree?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9597) checkWorkingCopyClean shouldn't complain about untracked empty folders (similar to git status)
[ https://issues.apache.org/jira/browse/LUCENE-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-9597. - Fix Version/s: master (9.0) Resolution: Fixed > checkWorkingCopyClean shouldn't complain about untracked empty folders > (similar to git status) > -- > > Key: LUCENE-9597 > URL: https://issues.apache.org/jira/browse/LUCENE-9597 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > > https://github.com/apache/lucene-solr/pull/2061 -- 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-9597) checkWorkingCopyClean shouldn't complain about untracked empty folders (similar to git status)
[ https://issues.apache.org/jira/browse/LUCENE-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225319#comment-17225319 ] ASF subversion and git services commented on LUCENE-9597: - Commit a29d7c70d5e26fd07660a0308106d10fdc4e9c29 in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a29d7c7 ] LUCENE-9597: checkWorkingCopyClean shouldn't complain about untracked empty folders (similar to git status). Piggybacking jgit update. (#2061) > checkWorkingCopyClean shouldn't complain about untracked empty folders > (similar to git status) > -- > > Key: LUCENE-9597 > URL: https://issues.apache.org/jira/browse/LUCENE-9597 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > > https://github.com/apache/lucene-solr/pull/2061 -- 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-14982) I don't understand method toQueryString of SolrParams.
[ https://issues.apache.org/jira/browse/SOLR-14982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14982. --- Resolution: Fixed Please raise questions like this on the user's list, we try to reserve JIRAs for known bugs/enhancements rather than usage questions. The JIRA system is not a support portal. See: http://lucene.apache.org/solr/community.html#mailing-lists-irc there are links to both Lucene and Solr mailing lists there. A _lot_ more people will see your question on that list and may be able to help more quickly. If it's determined that this really is a code issue or enhancement to Lucene or Solr and not a configuration/usage problem, we can raise a new JIRA or reopen this one. > I don't understand method toQueryString of SolrParams. > -- > > Key: SOLR-14982 > URL: https://issues.apache.org/jira/browse/SOLR-14982 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6.1 >Reporter: Warren Wen >Priority: Major > > I query string is " test. ". > I except it query in solr is " test. " also. But in *toQueryString(),* > it use URLEncoder.encode to decode query string, It will be change " " to > "", and solr server throw a error to me. Why use , not "%20" to > replace " "(space)? If use "%20" to replace " ", it will be ok in solr. > It is a bug? > -- 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-14912) Unify solr-contrib-extraction with the artifact it produces (solr-cell)
[
https://issues.apache.org/jira/browse/SOLR-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss resolved SOLR-14912.
Fix Version/s: master (9.0)
Resolution: Fixed
> Unify solr-contrib-extraction with the artifact it produces (solr-cell)
> ---
>
> Key: SOLR-14912
> URL: https://issues.apache.org/jira/browse/SOLR-14912
> Project: Solr
> Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
>
> This is similar to Lucene analysis/analyzers inconsistency. The
> 'solr/contrib/extraction' produces 'solr-contrib-cell' artifact. I suggest we
> should make it consistent and simpler by just producing
> 'solr-contrib-extraction' instead.
> {code}
> // This project has a different artifact name (solr-contrib-cell). Don't know
> why.
> configure(project(":solr:contrib:extraction")) {
> archivesBaseName = "solr-cell"
> }
> {code}
> https://github.com/apache/lucene-solr/pull/2060/files
--
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-14912) Unify solr-contrib-extraction with the artifact it produces (solr-cell)
[
https://issues.apache.org/jira/browse/SOLR-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225352#comment-17225352
]
ASF subversion and git services commented on SOLR-14912:
Commit 22296f28a27c58b9f6a013e334c922835e814d83 in lucene-solr's branch
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=22296f2 ]
SOLR-14912: Unify solr-contrib-extraction with the artifact it produces (#2060)
> Unify solr-contrib-extraction with the artifact it produces (solr-cell)
> ---
>
> Key: SOLR-14912
> URL: https://issues.apache.org/jira/browse/SOLR-14912
> Project: Solr
> Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
>
> This is similar to Lucene analysis/analyzers inconsistency. The
> 'solr/contrib/extraction' produces 'solr-contrib-cell' artifact. I suggest we
> should make it consistent and simpler by just producing
> 'solr-contrib-extraction' instead.
> {code}
> // This project has a different artifact name (solr-contrib-cell). Don't know
> why.
> configure(project(":solr:contrib:extraction")) {
> archivesBaseName = "solr-cell"
> }
> {code}
> https://github.com/apache/lucene-solr/pull/2060/files
--
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] cpoerschke merged pull request #2031: SOLR-14937: Correct client.queryDefaults().set(...) calls in some JSON facet tests.
cpoerschke merged pull request #2031: URL: https://github.com/apache/lucene-solr/pull/2031 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] iverase merged pull request #1940: LUCENE-9552: Adds a LatLonPoint query that accepts an array of LatLonGeometries
iverase merged pull request #1940: URL: https://github.com/apache/lucene-solr/pull/1940 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul closed pull request #1922: SOLR-14899: Make caches load from packages
noblepaul closed pull request #1922: URL: https://github.com/apache/lucene-solr/pull/1922 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 merged pull request #2058: SOLR-14981: Remove search results clustering contrib from 8x
dweiss merged pull request #2058: URL: https://github.com/apache/lucene-solr/pull/2058 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] ebourg opened a new pull request #2054: Typo in IndexWriter
ebourg opened a new pull request #2054: URL: https://github.com/apache/lucene-solr/pull/2054 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] janhoy merged pull request #2046: SOLR-14972: Change default port of prometheus exporter to 8989
janhoy merged pull request #2046: URL: https://github.com/apache/lucene-solr/pull/2046 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] jpountz merged pull request #1948: LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values.
jpountz merged pull request #1948: URL: https://github.com/apache/lucene-solr/pull/1948 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] cpoerschke merged pull request #2032: Rename TestSolrTestCaseJ4 to SolrTestCaseJ4DeleteCoreTest.
cpoerschke merged pull request #2032: URL: https://github.com/apache/lucene-solr/pull/2032 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] cpoerschke merged pull request #1870: SOLR-14865: 'Index Merge Metrics' documentation correction
cpoerschke merged pull request #1870: URL: https://github.com/apache/lucene-solr/pull/1870 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman merged pull request #1996: SOLR-14907: Adding V2 API for ConfigSet Upload.
HoustonPutman merged pull request #1996: URL: https://github.com/apache/lucene-solr/pull/1996 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 opened a new pull request #2058: SOLR-14981: Remove search results clustering contrib from 8x
dweiss opened a new pull request #2058: URL: https://github.com/apache/lucene-solr/pull/2058 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] radu-gheorghe opened a new pull request #2057: SOLR-14980: Added explanations on how facet methods are picked
radu-gheorghe opened a new pull request #2057: URL: https://github.com/apache/lucene-solr/pull/2057 To explain why, for example, `dvhash` doesn't work on multi-valued string fields. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [x] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] anshumg commented on a change in pull request #2012: SOLR-14935: Solr can forward request ( remoteQuery ) even if there are local cores present
anshumg commented on a change in pull request #2012:
URL: https://github.com/apache/lucene-solr/pull/2012#discussion_r516219411
##
File path: solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java
##
@@ -280,30 +280,37 @@ protected void init() throws Exception {
collectionsList =
resolveCollectionListOrAlias(queryParams.get(COLLECTION_PROP, def)); //
&collection= takes precedence
if (core == null) {
-// lookup core from collection, or route away if need to
-String collectionName = collectionsList.isEmpty() ? null :
collectionsList.get(0); // route to 1st
-//TODO try the other collections if can't find a local replica of the
first? (and do to V2HttpSolrCall)
-
boolean isPreferLeader = (path.endsWith("/update") ||
path.contains("/update/"));
-core = getCoreByCollection(collectionName, isPreferLeader); // find a
local replica/core for the collection
-if (core != null) {
- if (idx > 0) {
-path = path.substring(idx);
- }
-} else {
- // if we couldn't find it locally, look on other nodes
- if (idx > 0) {
-extractRemotePath(collectionName, origCorename);
-if (action == REMOTEQUERY) {
+// Let's try finding a local core
+for (String collectionName: collectionsList) {
+ core = getCoreByCollection(collectionName, isPreferLeader); // find
a local replica/core for the collection
+ if (core != null) {
+if (idx > 0) {
path = path.substring(idx);
- return;
}
+break;
+ }
+}
+ }
+
+ // There is no local core so using remoteQuery
+ //TODO try the other collections if can't find a local replica of the
first? (and do to V2HttpSolrCall)
+ if (core == null) {
+// lookup core from collection, or route away if need to
Review comment:
This part is going to route away as the lookup already failed locally by
this point. (just suggesting the comment fix :) )
##
File path: solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java
##
@@ -280,30 +280,37 @@ protected void init() throws Exception {
collectionsList =
resolveCollectionListOrAlias(queryParams.get(COLLECTION_PROP, def)); //
&collection= takes precedence
if (core == null) {
-// lookup core from collection, or route away if need to
-String collectionName = collectionsList.isEmpty() ? null :
collectionsList.get(0); // route to 1st
-//TODO try the other collections if can't find a local replica of the
first? (and do to V2HttpSolrCall)
-
boolean isPreferLeader = (path.endsWith("/update") ||
path.contains("/update/"));
-core = getCoreByCollection(collectionName, isPreferLeader); // find a
local replica/core for the collection
-if (core != null) {
- if (idx > 0) {
-path = path.substring(idx);
- }
-} else {
- // if we couldn't find it locally, look on other nodes
- if (idx > 0) {
-extractRemotePath(collectionName, origCorename);
-if (action == REMOTEQUERY) {
+// Let's try finding a local core
+for (String collectionName: collectionsList) {
+ core = getCoreByCollection(collectionName, isPreferLeader); // find
a local replica/core for the collection
+ if (core != null) {
+if (idx > 0) {
path = path.substring(idx);
- return;
}
+break;
+ }
+}
+ }
+
+ // There is no local core so using remoteQuery
+ //TODO try the other collections if can't find a local replica of the
first? (and do to V2HttpSolrCall)
+ if (core == null) {
+// lookup core from collection, or route away if need to
+String collectionName = collectionsList.isEmpty() ? null :
collectionsList.get(0); // route to 1st
+
+// if we couldn't find it locally, look on other nodes
Review comment:
`s/if//` ? We are sure we couldn't find the core locally by this point,
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] iverase opened a new pull request #2059: LUCENE-9595: Make Component2D#withinPoint implementations consistent with ShapeQuery logic
iverase opened a new pull request #2059: URL: https://github.com/apache/lucene-solr/pull/2059 This commit changes the logic of Component2D#withinPoint to return WithinRelation.NOTWITHIN when the point is inside the component. 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] anshumg commented on a change in pull request #1996: SOLR-14907: Adding V2 API for ConfigSet Upload.
anshumg commented on a change in pull request #1996: URL: https://github.com/apache/lucene-solr/pull/1996#discussion_r508680212 ## File path: solr/core/src/java/org/apache/solr/handler/admin/ConfigSetsHandler.java ## @@ -230,7 +231,9 @@ private void handleConfigUploadRequest(SolrQueryRequest req, SolrQueryResponse r ZipInputStream zis = new ZipInputStream(inputStream, StandardCharsets.UTF_8); ZipEntry zipEntry = null; +int entryCount = 0; Review comment: Can we just use a boolean 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] dweiss opened a new pull request #2060: SOLR-14912: Unify solr-contrib-extraction with the artifact it produces
dweiss opened a new pull request #2060: URL: https://github.com/apache/lucene-solr/pull/2060 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 merged pull request #2060: SOLR-14912: Unify solr-contrib-extraction with the artifact it produces
dweiss merged pull request #2060: URL: https://github.com/apache/lucene-solr/pull/2060 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 #1962: SOLR-14749 Provide a clean API for cluster-level event processing
noblepaul commented on a change in pull request #1962:
URL: https://github.com/apache/lucene-solr/pull/1962#discussion_r515762968
##
File path:
solr/core/src/java/org/apache/solr/core/ClusterEventProducerFactory.java
##
@@ -0,0 +1,178 @@
+package org.apache.solr.core;
+
+import org.apache.solr.api.CustomContainerPlugins;
+import org.apache.solr.cluster.events.ClusterEvent;
+import org.apache.solr.cluster.events.ClusterEventListener;
+import org.apache.solr.cluster.events.ClusterEventProducer;
+import org.apache.solr.cluster.events.impl.DefaultClusterEventProducer;
+
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Map;
+import java.util.Set;
+
+/**
+ * This class helps in handling the initial registration of plugin-based
listeners,
+ * when both the final {@link ClusterEventProducer} implementation and
listeners
+ * are configured using plugins.
+ */
+public class ClusterEventProducerFactory implements ClusterEventProducer {
+ private Map>
initialListeners = new HashMap<>();
+ private CustomContainerPlugins.PluginRegistryListener initialPluginListener;
+ private final CoreContainer cc;
+ private boolean created = false;
+
+ public ClusterEventProducerFactory(CoreContainer cc) {
+this.cc = cc;
+initialPluginListener = new
CustomContainerPlugins.PluginRegistryListener() {
+ @Override
+ public void added(CustomContainerPlugins.ApiInfo plugin) {
+if (plugin == null || plugin.getInstance() == null) {
+ return;
+}
+Object instance = plugin.getInstance();
+if (instance instanceof ClusterEventListener) {
+ registerListener((ClusterEventListener) instance);
+}
+ }
+
+ @Override
+ public void deleted(CustomContainerPlugins.ApiInfo plugin) {
+if (plugin == null || plugin.getInstance() == null) {
+ return;
+}
+Object instance = plugin.getInstance();
+if (instance instanceof ClusterEventListener) {
+ unregisterListener((ClusterEventListener) instance);
+}
+ }
+
+ @Override
+ public void modified(CustomContainerPlugins.ApiInfo old,
CustomContainerPlugins.ApiInfo replacement) {
+added(replacement);
+deleted(old);
+ }
+};
+ }
+
+ /**
+ * This method returns an initial plugin registry listener that helps to
capture the
+ * freshly loaded listener plugins before the final cluster event producer
is created.
+ * @return initial listener
+ */
+ public CustomContainerPlugins.PluginRegistryListener
getPluginRegistryListener() {
+return initialPluginListener;
+ }
+
+ /**
+ * Create a {@link ClusterEventProducer} based on the current plugin
configurations.
+ * NOTE: this method can only be called once because it has side-effects,
such as
+ * transferring the initially collected listeners to the resulting
producer's instance, and
+ * installing a {@link
org.apache.solr.api.CustomContainerPlugins.PluginRegistryListener}.
+ * Calling this method more than once will result in an exception.
+ * @param plugins current plugin configurations
+ * @return configured instance of cluster event producer (with side-effects,
see above)
+ */
+ public ClusterEventProducer create(CustomContainerPlugins plugins) {
+if (created) {
+ throw new RuntimeException("this factory can be called only once!");
+}
+final ClusterEventProducer clusterEventProducer;
+CustomContainerPlugins.ApiInfo clusterEventProducerInfo =
plugins.getPlugin(ClusterEventProducer.PLUGIN_NAME);
+if (clusterEventProducerInfo != null) {
+ // the listener in ClusterSingletons already registered it
+ clusterEventProducer = (ClusterEventProducer)
clusterEventProducerInfo.getInstance();
+} else {
+ // create the default impl
+ clusterEventProducer = new DefaultClusterEventProducer(cc);
Review comment:
NO , please.
I am -1 on enabling this by default
##
File path:
solr/core/src/java/org/apache/solr/core/ClusterEventProducerFactory.java
##
@@ -0,0 +1,178 @@
+package org.apache.solr.core;
+
+import org.apache.solr.api.CustomContainerPlugins;
+import org.apache.solr.cluster.events.ClusterEvent;
+import org.apache.solr.cluster.events.ClusterEventListener;
+import org.apache.solr.cluster.events.ClusterEventProducer;
+import org.apache.solr.cluster.events.impl.DefaultClusterEventProducer;
+
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Map;
+import java.util.Set;
+
+/**
+ * This class helps in handling the initial registration of plugin-based
listeners,
+ * when both the final {@link ClusterEventProducer} implementation and
listeners
+ * are configured using plugins.
+ */
+public class ClusterEventProducerFactory implements ClusterEventProducer {
+ private Map>
initialListeners = new HashMap<>();
+ private CustomContainerPlugins.PluginRegistryListener initialPluginListener;
+ private final CoreContai
[GitHub] [lucene-solr] cpoerschke commented on a change in pull request #1743: Gradual naming convention enforcement.
cpoerschke commented on a change in pull request #1743:
URL: https://github.com/apache/lucene-solr/pull/1743#discussion_r51673
##
File path:
lucene/test-framework/src/java/org/apache/lucene/util/VerifyTestClassNamingConvention.java
##
@@ -0,0 +1,98 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.util;
+
+import com.carrotsearch.randomizedtesting.RandomizedContext;
+import org.junit.Assume;
+
+import java.io.BufferedReader;
+import java.io.IOException;
+import java.io.InputStreamReader;
+import java.io.UncheckedIOException;
+import java.io.Writer;
+import java.nio.charset.StandardCharsets;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.nio.file.Paths;
+import java.nio.file.StandardOpenOption;
+import java.util.HashSet;
+import java.util.Set;
+import java.util.regex.Pattern;
+
+/**
+ * Enforce test naming convention.
+ */
+public class VerifyTestClassNamingConvention extends AbstractBeforeAfterRule {
+ public static final Pattern ALLOWED_CONVENTION =
Pattern.compile("(.+?)\\.Test[^.]+");
+
+ private static Set exceptions;
+ static {
+try {
+ exceptions = new HashSet<>();
+ try (BufferedReader is =
+ new BufferedReader(
+ new InputStreamReader(
+
VerifyTestClassNamingConvention.class.getResourceAsStream("test-naming-exceptions.txt"),
+ StandardCharsets.UTF_8))) {
+is.lines().forEach(exceptions::add);
+ }
+} catch (IOException e) {
+ throw new UncheckedIOException(e);
+}
+ }
+
+ @Override
+ protected void before() throws Exception {
+if (TestRuleIgnoreTestSuites.isRunningNested()) {
+ // Ignore nested test suites that test the test framework itself.
+ return;
+}
+
+String suiteName = RandomizedContext.current().getTargetClass().getName();
+
+// You can use this helper method to dump all suite names to a file.
+// Run gradle with one worker so that it doesn't try to append to the same
+// file from multiple processes:
+//
+// gradlew test --max-workers 1 -Dtests.useSecurityManager=false
+//
+// dumpSuiteNamesOnly(suiteName);
+
+if (!ALLOWED_CONVENTION.matcher(suiteName).matches()) {
+ // if this class exists on the exception list, leave it.
Review comment:
Added a commit to the PR re: this.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob opened a new pull request #2055: SOLR-14978 OOM Killer in Foreground
madrob opened a new pull request #2055: URL: https://github.com/apache/lucene-solr/pull/2055 https://issues.apache.org/jira/browse/SOLR-14978 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 merged pull request #2050: SOLR-14926: Modernize and clean up search results clustering contrib.
dweiss merged pull request #2050: URL: https://github.com/apache/lucene-solr/pull/2050 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 opened a new pull request #2061: LUCENE-9597: checkWorkingCopyClean shouldn't complain about untracked empty folders
dweiss opened a new pull request #2061: URL: https://github.com/apache/lucene-solr/pull/2061 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 merged pull request #2061: LUCENE-9597: checkWorkingCopyClean shouldn't complain about untracked empty folders
dweiss merged pull request #2061: URL: https://github.com/apache/lucene-solr/pull/2061 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] iverase merged pull request #1939: LUCENE-9553: Adds a XYPoint query that accepts an array of XYGeometries
iverase merged pull request #1939: URL: https://github.com/apache/lucene-solr/pull/1939 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] mocobeta merged pull request #2023: LUCENE-9319: Clean up package name conflicts for sandbox module
mocobeta merged pull request #2023: URL: https://github.com/apache/lucene-solr/pull/2023 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] gerlowskija opened a new pull request #2056: SOLR-14971: Handle atomic-removes on uncommitted docs
gerlowskija opened a new pull request #2056: URL: https://github.com/apache/lucene-solr/pull/2056 # Description Atomic Update 'remove' operations currently fail on several numeric fieldtypes when the "existing" doc hasn't been committed yet and is fetched from the UpdateLog. # Solution Modify logic for "remove" operation in AtomicUpdateDocumentMerger to check for comparable but different types (e.g. Long vs Integer). # Tests Manual testing for XML/JSON/javabin requests. Automated tests for Javabin and XML formats. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [ ] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob closed pull request #2042: SOLR-14961: ZkMaintenanceUtils.clean doesn't remove zk-nodes with same path length
madrob closed pull request #2042: URL: https://github.com/apache/lucene-solr/pull/2042 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 merged pull request #2054: Typo in IndexWriter
dweiss merged pull request #2054: URL: https://github.com/apache/lucene-solr/pull/2054 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] munendrasn commented on pull request #2056: SOLR-14971: Handle atomic-removes on uncommitted docs
munendrasn commented on pull request #2056: URL: https://github.com/apache/lucene-solr/pull/2056#issuecomment-721133321 > As PR is open, sharing the comment here instead of JIRA I was able to reproduce the issue with the script shared in JIRA. Regarding the approach, I agree SolrInputDocument returning field values in the actual type even for uncommitted docs is a better solution (approach 1) but currently not sure of the impact I was able to reproduce the same issue with `add-distinct` atomic operation too. `add`, `set` doesn't have this problem. I think `removeregex` might have the same issue but I'm assuming this operation would be used with string/text fields, so probably not an issue? 🤔 Coming to the PR, * This doesn't handle the case when the original values are passed as string. Suppose `values: ["2", "3"]`, then uncommitted doc would contain values as a string (This can happen if the users are using XML format (older version of solrJ sends update docs in XML format, not sure of the latest). In such cases, it will still not work * would the PR support date fields type too? I think to handle these cases, we need to convert the existing values to native types using Something like this but not sure of performance overhead in case of large fields ```java Collection original = existingField.getValues(); original.stream().map(val -> sf.getType().toNativeType(object)).collect(Collectors.toList()) ``` 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-14977) Container plugins need a way to be configured
[
https://issues.apache.org/jira/browse/SOLR-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225506#comment-17225506
]
Ilan Ginzburg commented on SOLR-14977:
--
[~ab], placement plugins configuration has (very) similar needs. The approach
is to type safe the configs (currently supporting {{String}}, {{Boolean}},
{{Long}}, {{Double}}) by returning each config type from a separate strongly
typed accessor (for example {{Long getLongConfig(String configName)}}).
This code could be renamed, moved, extended etc. to support more config types
and serve other plugin types.
The interface is
[PlacementPluginConfig|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cluster/placement/PlacementPluginConfig.java]
and implementation
[PlacementPluginConfigImpl|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cluster/placement/impl/PlacementPluginConfigImpl.java].
As described in the class Javadoc of
[PlacementPluginConfig|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cluster/placement/PlacementPluginConfig.java],
the configuration can be set doing:
{code:java}
curl -X POST -H 'Content-type:application/json' -d '{
"set-placement-plugin": {
"class": "factory.class.name$inner",
"myfirstString": "a text value",
"aLong": 50,
"aDoubleConfig": 3.1415928,
"shouldIStay": true
}' http://localhost:8983/api/cluster{code}
Which results in adding to {{/clusterprops.json}}:
{code:java}
"placement-plugin":{
"class":"factory.class.name$inner",
"myfirstString": "a text value",
"aLong": 50,
"aDoubleConfig": 3.1415928,
"shouldIStay": true}
{code}
> Container plugins need a way to be configured
> -
>
> Key: SOLR-14977
> URL: https://issues.apache.org/jira/browse/SOLR-14977
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Plugin system
>Reporter: Andrzej Bialecki
>Priority: Major
>
> Container plugins are defined in {{/clusterprops.json:/plugin}} using a
> simple {{PluginMeta}} bean. This is sufficient for implementations that don't
> need any configuration except for the {{pathPrefix}} but insufficient for
> anything else that needs more configuration parameters.
> An example would be a {{CollectionsRepairEventListener}} plugin proposed in
> PR-1962, which needs parameters such as the list of collections, {{waitFor}},
> maximum operations allowed, etc. to properly function.
> This issue proposes to extend the {{PluginMeta}} bean to allow a
> {{Map}} configuration parameters.
> There is an interface that we could potentially use ({{MapInitializedPlugin}}
> but it works only with {{String}} values. This is not optimal because it
> requires additional type-safety validation from the consumers. The existing
> {{PluginInfo}} / {{PluginInfoInitialized}} interface is too complex for this
> purpose.
--
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-14977) Container plugins need a way to be configured
[
https://issues.apache.org/jira/browse/SOLR-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225524#comment-17225524
]
Andrzej Bialecki commented on SOLR-14977:
-
Thanks [~ilan] this is very helpful, I think we should reuse this approach.
BTW, I think that the placement plugin info should live in the same place as
other plugins, there should be no need to put it in a separate sub-section of
/clusterprops.json. Then we could reuse the already existing mechanism for
plugin config monitoring, plugin reloading etc in {{CustomContainerPlugins}}.
This is what the {{ClusterSingleton}} and the upcoming {{ClusterEventProducer}}
use in order to enable dynamic reloading of plugins. But that's a separate
issue :)
> Container plugins need a way to be configured
> -
>
> Key: SOLR-14977
> URL: https://issues.apache.org/jira/browse/SOLR-14977
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Plugin system
>Reporter: Andrzej Bialecki
>Priority: Major
>
> Container plugins are defined in {{/clusterprops.json:/plugin}} using a
> simple {{PluginMeta}} bean. This is sufficient for implementations that don't
> need any configuration except for the {{pathPrefix}} but insufficient for
> anything else that needs more configuration parameters.
> An example would be a {{CollectionsRepairEventListener}} plugin proposed in
> PR-1962, which needs parameters such as the list of collections, {{waitFor}},
> maximum operations allowed, etc. to properly function.
> This issue proposes to extend the {{PluginMeta}} bean to allow a
> {{Map}} configuration parameters.
> There is an interface that we could potentially use ({{MapInitializedPlugin}}
> but it works only with {{String}} values. This is not optimal because it
> requires additional type-safety validation from the consumers. The existing
> {{PluginInfo}} / {{PluginInfoInitialized}} interface is too complex for this
> purpose.
--
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-9542) Score returned in search request is original score and not reranked score
[
https://issues.apache.org/jira/browse/LUCENE-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225542#comment-17225542
]
Christine Poerschke commented on LUCENE-9542:
-
Thanks [~krishan1390] for the clarification that this was happening on the LTR
reranker when "sort" is present and thanks [~Baik] for the reproducing unit
test and analysis!
Based on that then here's a {{techproducts}} request/response illustration:
{code:java}
$ curl
'http://localhost:8983/solr/techproducts/select?fl=id,score&q=inStock:true&fq=cat:memory&rq=\{!rerank+reRankQuery=id:VDBDB1A16\}&sort=score+desc'
{
"responseHeader":{
"status":0,
"QTime":3,
"params":{
"q":"inStock:true",
"fl":"id,score",
"fq":"cat:memory",
"sort":"score desc",
"rq":"{!rerank reRankQuery=id:VDBDB1A16}"}},
"response":{"numFound":3,"start":0,"maxScore":0.10401889,"numFoundExact":true,"docs":[
{
"id":"VDBDB1A16",
"score":2.9140575},
{
"id":"TWINX2048-3200PRO",
"score":0.10401889},
{
"id":"VS1GB400C3",
"score":0.10401889}]
}}
{code}
vs.
{code:java}
$ curl
'http://localhost:8983/solr/techproducts/select?fl=id,score&q=inStock:true&fq=cat:memory&rq=\{!rerank+reRankQuery=id:VDBDB1A16\}&sort=score+desc,id+asc'
{
"responseHeader":{
"status":0,
"QTime":0,
"params":{
"q":"inStock:true",
"fl":"id,score",
"fq":"cat:memory",
"sort":"score desc,id asc",
"rq":"{!rerank reRankQuery=id:VDBDB1A16}"}},
"response":{"numFound":3,"start":0,"maxScore":0.10401889,"numFoundExact":true,"docs":[
{
"id":"VDBDB1A16",
"score":0.10401889},
{
"id":"TWINX2048-3200PRO",
"score":0.10401889},
{
"id":"VS1GB400C3",
"score":0.10401889}]
}}
{code}
(I'm going to move this JIRA ticket across from LUCENE to SOLR for visibility
and since this concerns the {{SolrIndexSearcher}} class. Any use of
https://issues.apache.org/jira/browse/LUCENE-9542 should then redirect
seamlessly to the SOLR ticket.)
> Score returned in search request is original score and not reranked score
> -
>
> Key: LUCENE-9542
> URL: https://issues.apache.org/jira/browse/LUCENE-9542
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 8.0
>Reporter: Krishan
>Priority: Major
> Attachments: 0001-LUCENE-9542-Unit-test-to-reproduce-bug.patch
>
>
> Score returned in search request is original score and not reranked score
> post the changes in https://issues.apache.org/jira/browse/LUCENE-8412.
> Commit -
> [https://github.com/apache/lucene-solr/commit/55bfadbce115a825a75686fe0bfe71406bc3ee44#diff-4e354f104ed52bd7f620b0c05ae8467d]
> Specifically -
> if (cmd.getSort() != null && query instanceof RankQuery == false &&
> (cmd.getFlags() & GET_SCORES) != 0) {
> TopFieldCollector.populateScores(topDocs.scoreDocs, this, query);
> }
> in SolrIndexSearcher.java recomputes the score but outputs only the original
> score and not the reranked score.
>
> The issue is cmd.getQuery() is a type of RankQuery but the "query" variable
> is a boolean query and probably replacing query with cmd.getQuery() should be
> the right fix for this so that the score is not overriden for rerank queries
>
--
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] [Moved] (SOLR-14983) Score returned in search request is original score and not reranked score
[
https://issues.apache.org/jira/browse/SOLR-14983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke moved LUCENE-9542 to SOLR-14983:
Key: SOLR-14983 (was: LUCENE-9542)
Lucene Fields: (was: New)
Affects Version/s: (was: 8.0)
8.0
Project: Solr (was: Lucene - Core)
> Score returned in search request is original score and not reranked score
> -
>
> Key: SOLR-14983
> URL: https://issues.apache.org/jira/browse/SOLR-14983
> Project: Solr
> Issue Type: Bug
>Affects Versions: 8.0
>Reporter: Krishan
>Priority: Major
> Attachments: 0001-LUCENE-9542-Unit-test-to-reproduce-bug.patch
>
>
> Score returned in search request is original score and not reranked score
> post the changes in https://issues.apache.org/jira/browse/LUCENE-8412.
> Commit -
> [https://github.com/apache/lucene-solr/commit/55bfadbce115a825a75686fe0bfe71406bc3ee44#diff-4e354f104ed52bd7f620b0c05ae8467d]
> Specifically -
> if (cmd.getSort() != null && query instanceof RankQuery == false &&
> (cmd.getFlags() & GET_SCORES) != 0) {
> TopFieldCollector.populateScores(topDocs.scoreDocs, this, query);
> }
> in SolrIndexSearcher.java recomputes the score but outputs only the original
> score and not the reranked score.
>
> The issue is cmd.getQuery() is a type of RankQuery but the "query" variable
> is a boolean query and probably replacing query with cmd.getQuery() should be
> the right fix for this so that the score is not overriden for rerank queries
>
--
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-14983) Score returned in search request is original score and not reranked score
[
https://issues.apache.org/jira/browse/SOLR-14983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-14983:
---
Attachment: SOLR-14983.patch
> Score returned in search request is original score and not reranked score
> -
>
> Key: SOLR-14983
> URL: https://issues.apache.org/jira/browse/SOLR-14983
> Project: Solr
> Issue Type: Bug
>Affects Versions: 8.0
>Reporter: Krishan
>Priority: Major
> Attachments: 0001-LUCENE-9542-Unit-test-to-reproduce-bug.patch,
> SOLR-14983.patch
>
>
> Score returned in search request is original score and not reranked score
> post the changes in https://issues.apache.org/jira/browse/LUCENE-8412.
> Commit -
> [https://github.com/apache/lucene-solr/commit/55bfadbce115a825a75686fe0bfe71406bc3ee44#diff-4e354f104ed52bd7f620b0c05ae8467d]
> Specifically -
> if (cmd.getSort() != null && query instanceof RankQuery == false &&
> (cmd.getFlags() & GET_SCORES) != 0) {
> TopFieldCollector.populateScores(topDocs.scoreDocs, this, query);
> }
> in SolrIndexSearcher.java recomputes the score but outputs only the original
> score and not the reranked score.
>
> The issue is cmd.getQuery() is a type of RankQuery but the "query" variable
> is a boolean query and probably replacing query with cmd.getQuery() should be
> the right fix for this so that the score is not overriden for rerank queries
>
--
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-14983) Score returned in search request is original score and not reranked score
[
https://issues.apache.org/jira/browse/SOLR-14983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225544#comment-17225544
]
Christine Poerschke commented on SOLR-14983:
Attached SOLR-14983.patch file
* has the proposed {{cmd.getQuery()}} instead of {{query}} fix
* adds a {{testReranking}} case into the existing {{SolrIndexSearcherTest}}
suite using [~Baik]'s 0001-LUCENE-9542-Unit-test-to-reproduce-bug.patch
approach of a private {{RankQuery}} class that produces known value scores.
What do you think?
> Score returned in search request is original score and not reranked score
> -
>
> Key: SOLR-14983
> URL: https://issues.apache.org/jira/browse/SOLR-14983
> Project: Solr
> Issue Type: Bug
>Affects Versions: 8.0
>Reporter: Krishan
>Priority: Major
> Attachments: 0001-LUCENE-9542-Unit-test-to-reproduce-bug.patch,
> SOLR-14983.patch
>
>
> Score returned in search request is original score and not reranked score
> post the changes in https://issues.apache.org/jira/browse/LUCENE-8412.
> Commit -
> [https://github.com/apache/lucene-solr/commit/55bfadbce115a825a75686fe0bfe71406bc3ee44#diff-4e354f104ed52bd7f620b0c05ae8467d]
> Specifically -
> if (cmd.getSort() != null && query instanceof RankQuery == false &&
> (cmd.getFlags() & GET_SCORES) != 0) {
> TopFieldCollector.populateScores(topDocs.scoreDocs, this, query);
> }
> in SolrIndexSearcher.java recomputes the score but outputs only the original
> score and not the reranked score.
>
> The issue is cmd.getQuery() is a type of RankQuery but the "query" variable
> is a boolean query and probably replacing query with cmd.getQuery() should be
> the right fix for this so that the score is not overriden for rerank queries
>
--
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-9598) Improve the summary of Jenkins emails on failure
Dawid Weiss created LUCENE-9598:
---
Summary: Improve the summary of Jenkins emails on failure
Key: LUCENE-9598
URL: https://issues.apache.org/jira/browse/LUCENE-9598
Project: Lucene - Core
Issue Type: Improvement
Reporter: Dawid Weiss
Where are the patterns that drive what's extracted from the console logs sent
to builds mailing list? I think these could be improved to include more context
starting after "FAILURE" - then you know which task failed exactly, not just
that the build failed.
{code}
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':solr:solr-ref-guide:checkLocalJavadocLinksSite'.
> Process 'command '/usr/local/asfpackages/java/jdk-11.0.6/bin/java'' finished
> with non-zero exit value 255
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with
Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See
https://docs.gradle.org/6.6.1/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 1h 6m 1s
852 actionable tasks: 852 executed
Build step 'Invoke Gradle script' changed build result to FAILURE
Build step 'Invoke Gradle script' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
[Email-ext] Notification email body length: 446
Sending email to: bui...@lucene.apache.org
Finished: FAILURE
{code}
--
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] HoustonPutman commented on a change in pull request #2055: SOLR-14978 OOM Killer in Foreground
HoustonPutman commented on a change in pull request #2055:
URL: https://github.com/apache/lucene-solr/pull/2055#discussion_r516805804
##
File path: solr/bin/solr
##
@@ -2172,6 +2172,12 @@ function start_solr() {
SOLR_OPTS+=($AUTHC_OPTS)
fi
+ # If a heap dump directory is specified, enable it in SOLR_OPTS
+ if [[ -n "$SOLR_HEAP_DUMP_DIR" ]]; then
Review comment:
I kind of like the idea of having a boolean flag to turn on heap dumps,
and have a default location in the logs directory. This logic would be fine,
but having an additional check above that checks that `SOLR_HEAP_DUMP_DIR` is
empty and `SOLR_HEAP_DUMP` is true, then sets
`SOLR_HEAP_DUMP_DIR="${SOLR_LOG_DIR}/dumps"`.
Just a thought, for ease of use.
##
File path: solr/docker/include/scripts/solr-fg
##
@@ -15,21 +15,19 @@ if [[ -z "${OOM:-}" ]]; then
OOM='none'
fi
case "$OOM" in
Review comment:
Should this also be moved to bin/solr?
##
File path: solr/bin/solr
##
@@ -2172,6 +2172,12 @@ function start_solr() {
SOLR_OPTS+=($AUTHC_OPTS)
fi
Review comment:
```suggestion
# If a heap dump directory is specified, enable it in SOLR_OPTS
if [[ -z "$SOLR_HEAP_DUMP_DIR" ]] && [[ "$SOLR_HEAP_DUMP" == "true" ]]; then
SOLR_HEAP_DUMP_DIR="${SOLR_LOGS_DIR}/dumps"
fi
```
I like the idea of having a boolean flag that lets you say that you want a
heap dump at the default location of heap dumps. Not a necessity, just a
thought.
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-9598) Improve the summary of Jenkins emails on failure
[
https://issues.apache.org/jira/browse/LUCENE-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225548#comment-17225548
]
Dawid Weiss commented on LUCENE-9598:
-
I spoke with Uwe - these patterns are manually set up for each and every job.
Maybe we can make it saner some time in the future - we'll see.
> Improve the summary of Jenkins emails on failure
>
>
> Key: LUCENE-9598
> URL: https://issues.apache.org/jira/browse/LUCENE-9598
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Dawid Weiss
>Priority: Minor
>
> Where are the patterns that drive what's extracted from the console logs sent
> to builds mailing list? I think these could be improved to include more
> context starting after "FAILURE" - then you know which task failed exactly,
> not just that the build failed.
> {code}
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':solr:solr-ref-guide:checkLocalJavadocLinksSite'.
> > Process 'command '/usr/local/asfpackages/java/jdk-11.0.6/bin/java''
> > finished with non-zero exit value 255
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> Deprecated Gradle features were used in this build, making it incompatible
> with Gradle 7.0.
> Use '--warning-mode all' to show the individual deprecation warnings.
> See
> https://docs.gradle.org/6.6.1/userguide/command_line_interface.html#sec:command_line_warnings
> BUILD FAILED in 1h 6m 1s
> 852 actionable tasks: 852 executed
> Build step 'Invoke Gradle script' changed build result to FAILURE
> Build step 'Invoke Gradle script' marked build as failure
> Archiving artifacts
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
> [Email-ext] Notification email body length: 446
> Sending email to: bui...@lucene.apache.org
> Finished: FAILURE
> {code}
--
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-9598) Improve the summary of Jenkins emails on failure
[
https://issues.apache.org/jira/browse/LUCENE-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225554#comment-17225554
]
Uwe Schindler commented on LUCENE-9598:
---
Hi, the current config of the email-ext plugin is the following:
eMail-Contents:
{noformat}
Build: ${BUILD_URL}
Java: ${ENV,var="JAVA_DESC"}
${FAILED_TESTS}
Build Log:
${BUILD_LOG_MULTILINE_REGEX,regex="(?x:
\
\
(?:.*\\[javac\\]\\s++(?![1-9]\\d*\\s+error).*\\r?\\n)*+.*\\[javac\\]\\s+[1-9]\\d*\\s+error.*\\r?\\n
\
\
|.*\\[junit4\\]\\s+Suite:.*+\\s++
\
(?:.*\\[junit4\\]\\s++(?!Suite:)(?!Completed).*\\r?\\n)*+
\
.*\\[junit4\\]\\s++Completed\\s+.*<<<\\s*FAILURES!\\r?\\n
\
\
|.*\\[junit4\\]\\s+JVM\\s+J\\d+:\\s+std(?:out|err)\\s+was\\s+not\\s+empty.*+\\s++
\
(?:.*\\[junit4\\]\\s++(?!JVM\\s+\\d+:\\s+std)(?!\\<<<\\s+JVM\\s+J\\d+:\\s+EOF).*\\r?\\n)*+
\
.*\\[junit4\\]\\s++<<<\\s+JVM\\s+J\\d+:\\s+EOF.*\\r?\\n
\
\
|.*rat-sources:.*\\r?\\n
\
(?:\\s*+\\[echo\\]\\s*\\r?\\n|\\s*+\\[echo\\]\\s++(?![1-9]\\d*\\s+Unknown\\s+License)\\S.*\\r?\\n)*+
\
\\s*+\\[echo\\]\\s+[1-9]\\d*\\s+Unknown\\s+License.*\\r?\\n
\
(?:\\s*+\\[echo\\].*\\r?\\n)*+
\
\
|(?:.*\\r?\\n){2}.*\\[licenses\\]\\s+MISSING\\s+sha1(?:.*\\r?\\n){2}
\
\
|.*check-licenses:.*\\r?\\n\\s*\\[echo\\].*\\r?\\n
\
\\s*\\[licenses\\]\\s+(?:MISSING\\s+LICENSE|CHECKSUM\\s+FAILED).*\\r?\\n
\
(?:\\s*+\\[licenses\\].*\\r?\\n)++
\
\
|(?:.*\\[javadoc\\]\\s++(?![1-9]\\d*\\s+(?:error|warning)).+\\r?\\n)*+
\
.*\\[javadoc\\]\\s+[1-9]\\d*\\s+(?:error|warning).*\\r?\\n
\
\
|.*javadocs-lint:.*\\r?\\n(?:.*\\[exec\\].*\\r?\\n)*+
\
\
|.*check.*:.*\\r?\\n
\
(?:\\s*+\\[forbidden-apis\\]\\s*\\r?\\n
\
|\\s*+\\[forbidden-apis\\]\\s++
[jira] [Commented] (LUCENE-9598) Improve the summary of Jenkins emails on failure
[
https://issues.apache.org/jira/browse/LUCENE-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225556#comment-17225556
]
Dawid Weiss commented on LUCENE-9598:
-
Ouch. This is pretty wild. And it contains stuff no longer relevant to gradle
builds. I'll try to take a look at it - hairy.
> Improve the summary of Jenkins emails on failure
>
>
> Key: LUCENE-9598
> URL: https://issues.apache.org/jira/browse/LUCENE-9598
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Dawid Weiss
>Priority: Minor
>
> Where are the patterns that drive what's extracted from the console logs sent
> to builds mailing list? I think these could be improved to include more
> context starting after "FAILURE" - then you know which task failed exactly,
> not just that the build failed.
> {code}
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':solr:solr-ref-guide:checkLocalJavadocLinksSite'.
> > Process 'command '/usr/local/asfpackages/java/jdk-11.0.6/bin/java''
> > finished with non-zero exit value 255
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> Deprecated Gradle features were used in this build, making it incompatible
> with Gradle 7.0.
> Use '--warning-mode all' to show the individual deprecation warnings.
> See
> https://docs.gradle.org/6.6.1/userguide/command_line_interface.html#sec:command_line_warnings
> BUILD FAILED in 1h 6m 1s
> 852 actionable tasks: 852 executed
> Build step 'Invoke Gradle script' changed build result to FAILURE
> Build step 'Invoke Gradle script' marked build as failure
> Archiving artifacts
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
> [Email-ext] Notification email body length: 446
> Sending email to: bui...@lucene.apache.org
> Finished: FAILURE
> {code}
--
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-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225573#comment-17225573
]
Tim Owen commented on SOLR-8673:
No, still can't define new aggregates in custom code. That class is now public
since 8.6.. but all its fields have package-visibility and there are not even
any get methods, so it's impossible to use it.
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
--
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-9598) Improve the summary of Jenkins emails on failure
[
https://issues.apache.org/jira/browse/LUCENE-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225579#comment-17225579
]
Uwe Schindler commented on LUCENE-9598:
---
bq. Ouch. This is pretty wild.
The regex hell!
> Improve the summary of Jenkins emails on failure
>
>
> Key: LUCENE-9598
> URL: https://issues.apache.org/jira/browse/LUCENE-9598
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Dawid Weiss
>Priority: Minor
>
> Where are the patterns that drive what's extracted from the console logs sent
> to builds mailing list? I think these could be improved to include more
> context starting after "FAILURE" - then you know which task failed exactly,
> not just that the build failed.
> {code}
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':solr:solr-ref-guide:checkLocalJavadocLinksSite'.
> > Process 'command '/usr/local/asfpackages/java/jdk-11.0.6/bin/java''
> > finished with non-zero exit value 255
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> Deprecated Gradle features were used in this build, making it incompatible
> with Gradle 7.0.
> Use '--warning-mode all' to show the individual deprecation warnings.
> See
> https://docs.gradle.org/6.6.1/userguide/command_line_interface.html#sec:command_line_warnings
> BUILD FAILED in 1h 6m 1s
> 852 actionable tasks: 852 executed
> Build step 'Invoke Gradle script' changed build result to FAILURE
> Build step 'Invoke Gradle script' marked build as failure
> Archiving artifacts
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
> [Email-ext] Notification email body length: 446
> Sending email to: bui...@lucene.apache.org
> Finished: FAILURE
> {code}
--
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-14983) Score returned in search request is original score and not reranked score
[
https://issues.apache.org/jira/browse/SOLR-14983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225605#comment-17225605
]
Jason Baik commented on SOLR-14983:
---
Looks good on our side.
> Score returned in search request is original score and not reranked score
> -
>
> Key: SOLR-14983
> URL: https://issues.apache.org/jira/browse/SOLR-14983
> Project: Solr
> Issue Type: Bug
>Affects Versions: 8.0
>Reporter: Krishan
>Priority: Major
> Attachments: 0001-LUCENE-9542-Unit-test-to-reproduce-bug.patch,
> SOLR-14983.patch
>
>
> Score returned in search request is original score and not reranked score
> post the changes in https://issues.apache.org/jira/browse/LUCENE-8412.
> Commit -
> [https://github.com/apache/lucene-solr/commit/55bfadbce115a825a75686fe0bfe71406bc3ee44#diff-4e354f104ed52bd7f620b0c05ae8467d]
> Specifically -
> if (cmd.getSort() != null && query instanceof RankQuery == false &&
> (cmd.getFlags() & GET_SCORES) != 0) {
> TopFieldCollector.populateScores(topDocs.scoreDocs, this, query);
> }
> in SolrIndexSearcher.java recomputes the score but outputs only the original
> score and not the reranked score.
>
> The issue is cmd.getQuery() is a type of RankQuery but the "query" variable
> is a boolean query and probably replacing query with cmd.getQuery() should be
> the right fix for this so that the score is not overriden for rerank queries
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on pull request #2043: SOLR-14963: only count 1st level children in ChildDocTranformer limit
dsmiley commented on pull request #2043: URL: https://github.com/apache/lucene-solr/pull/2043#issuecomment-721361220 I don't think the limit should only apply to the first level 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
[jira] [Commented] (SOLR-14963) Child "rows" param should apply per level
[
https://issues.apache.org/jira/browse/SOLR-14963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225660#comment-17225660
]
David Smiley commented on SOLR-14963:
-
Eh; I don't think the limit should only apply to the root.
> Child "rows" param should apply per level
> -
>
> Key: SOLR-14963
> URL: https://issues.apache.org/jira/browse/SOLR-14963
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{[child rows=10]}} doc transformer "rows" param _should_ apply per
> parent, and it's documented this way: "The maximum number of child documents
> to be returned per parent document.". However, it is instead implemented as
> an overall limit as the child documents are processed in a depth-first order
> way. The implementation ought to change.
--
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] muse-dev[bot] commented on a change in pull request #1962: SOLR-14749 Provide a clean API for cluster-level event processing
muse-dev[bot] commented on a change in pull request #1962:
URL: https://github.com/apache/lucene-solr/pull/1962#discussion_r516960732
##
File path:
solr/core/src/java/org/apache/solr/cluster/events/ClusterEventProducerBase.java
##
@@ -0,0 +1,85 @@
+package org.apache.solr.cluster.events;
+
+import org.apache.solr.core.CoreContainer;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.lang.invoke.MethodHandles;
+import java.util.Collections;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
+
+/**
+ *
+ */
+public abstract class ClusterEventProducerBase implements ClusterEventProducer
{
+ private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
+
+ protected final Map>
listeners = new ConcurrentHashMap<>();
+ protected volatile State state = State.STOPPED;
+ protected final CoreContainer cc;
+
+ protected ClusterEventProducerBase(CoreContainer cc) {
+this.cc = cc;
+ }
+
+ @Override
+ public void registerListener(ClusterEventListener listener,
ClusterEvent.EventType... eventTypes) {
+if (eventTypes == null || eventTypes.length == 0) {
+ eventTypes = ClusterEvent.EventType.values();
+}
+for (ClusterEvent.EventType type : eventTypes) {
+ if (!getSupportedEventTypes().contains(type)) {
+log.warn("event type {} not supported yet.", type);
+continue;
+ }
+ // to avoid removing no-longer empty set in unregister
+ synchronized (listeners) {
+listeners.computeIfAbsent(type, t -> ConcurrentHashMap.newKeySet())
+.add(listener);
+ }
+}
+ }
+
+ @Override
+ public void unregisterListener(ClusterEventListener listener,
ClusterEvent.EventType... eventTypes) {
+if (eventTypes == null || eventTypes.length == 0) {
+ eventTypes = ClusterEvent.EventType.values();
+}
+synchronized (listeners) {
+ for (ClusterEvent.EventType type : eventTypes) {
+Set perType = listeners.get(type);
+if (perType != null) {
+ perType.remove(listener);
+ if (perType.isEmpty()) {
+listeners.remove(type);
+ }
+}
+ }
+}
+ }
+
+ @Override
+ public State getState() {
+return state;
+ }
+
+ public Map>
getEventListeners() {
+return listeners;
+ }
+
+ public CoreContainer getCoreContainer() {
+return cc;
+ }
+
+ public abstract Set getSupportedEventTypes();
+
+ protected void fireEvent(ClusterEvent event) {
+listeners.getOrDefault(event.getType(), Collections.emptySet())
Review comment:
*THREAD_SAFETY_VIOLATION:* Read/Write race. Non-private method
`ClusterEventProducerBase.fireEvent(...)` reads without synchronization from
container `this.listeners` via call to `Map.getOrDefault(...)`. Potentially
races with write in method `ClusterEventProducerBase.unregisterListener(...)`.
Reporting because another access to the same memory occurs on a background
thread, although this access may not.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on a change in pull request #2055: SOLR-14978 OOM Killer in Foreground
madrob commented on a change in pull request #2055:
URL: https://github.com/apache/lucene-solr/pull/2055#discussion_r516974593
##
File path: solr/docker/include/scripts/solr-fg
##
@@ -15,21 +15,19 @@ if [[ -z "${OOM:-}" ]]; then
OOM='none'
fi
case "$OOM" in
Review comment:
I don't think so. It might make sense to remove it entirely, but in
bin/solr these options can be specified directly instead.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman commented on a change in pull request #2055: SOLR-14978 OOM Killer in Foreground
HoustonPutman commented on a change in pull request #2055:
URL: https://github.com/apache/lucene-solr/pull/2055#discussion_r516976500
##
File path: solr/docker/include/scripts/solr-fg
##
@@ -15,21 +15,19 @@ if [[ -z "${OOM:-}" ]]; then
OOM='none'
fi
case "$OOM" in
Review comment:
I wonder what effect these even have if we are going to run the
oom_script by default, which will kill the solr process
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-14788) Solr: The Next Big Thing
[
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225833#comment-17225833
]
Mark Robert Miller commented on SOLR-14788:
---
Okay, things are really rolling. I hate to make it seem like things will never
be done as I solve one more issue, but hardening our worst tests forced me to
take one more look at the Overseer.
The last time I mad a Mark Miller Solr branch, after working with our
distributed queue implementation, I settled on the fact that it was terrible
for our use case and the implementation was lacking regardless. At that point I
tossed the Overseer and started on the SolrSeer, doing things more how I’d
approach them. This time, trying to be conservative, I settled on trying to
make the existing queue and logic as good as it can be. Progress not
perfection, we can deal with the Overseer more fully later.
However, as I started in on the unignores for some of our most flakey and
problematic and sometimes esoteric tests, it became clear things were
fundamentally flawed in a way that can’t be punted.
The way that we did things incrementally put us in an absurd place in terms of
collection/config admin and cluster state structure and Replica/Shard ACTIVE
states.
The fact that we have two overseer threads and queues, each with different
levels of concurrency and blocking, is very problematic because the commands
from the queue are dependent on each other.
When you add in the fact that we essentially have a split brain in terms of who
really owns the clusterstate, and still attempted mix support of predefined
cores or collection API cores, and the problems just flow on and on from there.
So as I looked at making that whole bag of ugliness reasonable, the solution is
very close to the approach I was going for with the SolrSeer.
When you put it on top of the work I already did with the ZKStateWriter, it’s a
game changer that I won’t even try to do credit, it’s something that will
happily speak for itself.
With great caution, I hazard that that is my last lack of sleep, binge effort.
I still have to call back my mom from a missed call last week - it’s been a
constant question in my household- where the hell is Mark, I don’t think he
lives here :) I’m ready for it to end as much as anyone.
So I wrap this up and hit the rest of those tests ASAP, non binge style, and
then it’s catch up to master. It doesn’t ever quite seem it, but it’s coming.
It’s coming soon.
> Solr: The Next Big Thing
>
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Critical
>
> h3.
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
> Policeman is on duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and
> have some fun. Try to make some progress. Don't stress too much about the
> impact of your changes or maintaining stability and performance and
> correctness so much. Until the end of phase 1, I've got your back. I have a
> variety of tools and contraptions I have been building over the years and I
> will continue training them on this branch. I will review your changes and
> peer out across the land and course correct where needed. As Mike D will be
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some
> extent. Which is why once stage one is completed, I will flip The Policeman
> to off duty. When off duty, I'm always* {color:#de350b}*occasionally*{color}
> *down for some vigilante justice, but I won't be walking the beat, all that
> stuff about sit back and relax goes out the window.*{color}_
> {quote}
>
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and
> Noble have already contributed support and testing and have plans for
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.
--
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-14977) Container plugins need a way to be configured
[
https://issues.apache.org/jira/browse/SOLR-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225838#comment-17225838
]
Noble Paul commented on SOLR-14977:
---
I agree with [~ab]
The model followed by {{ClusterSingleton}} and {{ClusterEventProducer}} is
something we can follow here as well
> Container plugins need a way to be configured
> -
>
> Key: SOLR-14977
> URL: https://issues.apache.org/jira/browse/SOLR-14977
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Plugin system
>Reporter: Andrzej Bialecki
>Priority: Major
>
> Container plugins are defined in {{/clusterprops.json:/plugin}} using a
> simple {{PluginMeta}} bean. This is sufficient for implementations that don't
> need any configuration except for the {{pathPrefix}} but insufficient for
> anything else that needs more configuration parameters.
> An example would be a {{CollectionsRepairEventListener}} plugin proposed in
> PR-1962, which needs parameters such as the list of collections, {{waitFor}},
> maximum operations allowed, etc. to properly function.
> This issue proposes to extend the {{PluginMeta}} bean to allow a
> {{Map}} configuration parameters.
> There is an interface that we could potentially use ({{MapInitializedPlugin}}
> but it works only with {{String}} values. This is not optimal because it
> requires additional type-safety validation from the consumers. The existing
> {{PluginInfo}} / {{PluginInfoInitialized}} interface is too complex for this
> purpose.
--
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-14977) Container plugins need a way to be configured
[
https://issues.apache.org/jira/browse/SOLR-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225848#comment-17225848
]
Noble Paul commented on SOLR-14977:
---
Let's have a simple interface as follows (change the name as you wish).
This will help us do a type-safe initialization of any plugin.
{code:java}
public interface SimplePlugin {
public void initPlugin(T initVals);
}
{code}
> Container plugins need a way to be configured
> -
>
> Key: SOLR-14977
> URL: https://issues.apache.org/jira/browse/SOLR-14977
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Plugin system
>Reporter: Andrzej Bialecki
>Priority: Major
>
> Container plugins are defined in {{/clusterprops.json:/plugin}} using a
> simple {{PluginMeta}} bean. This is sufficient for implementations that don't
> need any configuration except for the {{pathPrefix}} but insufficient for
> anything else that needs more configuration parameters.
> An example would be a {{CollectionsRepairEventListener}} plugin proposed in
> PR-1962, which needs parameters such as the list of collections, {{waitFor}},
> maximum operations allowed, etc. to properly function.
> This issue proposes to extend the {{PluginMeta}} bean to allow a
> {{Map}} configuration parameters.
> There is an interface that we could potentially use ({{MapInitializedPlugin}}
> but it works only with {{String}} values. This is not optimal because it
> requires additional type-safety validation from the consumers. The existing
> {{PluginInfo}} / {{PluginInfoInitialized}} interface is too complex for this
> purpose.
--
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-14923) Indexing performance is unacceptable when child documents are involved
[ https://issues.apache.org/jira/browse/SOLR-14923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225901#comment-17225901 ] Thomas Wöckinger commented on SOLR-14923: - [~dsmiley] Last investigations on this issue showed that flagging the UpdateLog to open a new RealTimeSearcher (as you mentionend at https://issues.apache.org/jira/browse/SOLR-12638?focusedCommentId=16872898&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16872898) seems to be the best solution. So i can start working on this, a question in advance: Would it be sufficient to track the document ids which require a reload and clear them on each openRealTimeSearcher call? > Indexing performance is unacceptable when child documents are involved > -- > > Key: SOLR-14923 > URL: https://issues.apache.org/jira/browse/SOLR-14923 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: update, UpdateRequestProcessors >Affects Versions: master (9.0), 8.3, 8.4, 8.5, 8.6 >Reporter: Thomas Wöckinger >Priority: Critical > Labels: performance > > Parallel indexing does not make sense at moment when child documents are used. > The org.apache.solr.update.processor.DistributedUpdateProcessor checks at the > end of the method doVersionAdd if Ulog caches should be refreshed. > This check will return true if any child document is included in the > AddUpdateCommand. > If so ulog.openRealtimeSearcher(); is called, this call is very expensive, > and executed in a synchronized block of the UpdateLog instance, therefore all > other operations on the UpdateLog are blocked too. > Because every important UpdateLog method (add, delete, ...) is done using a > synchronized block almost each operation is blocked. > This reduces multi threaded index update to a single thread behavior. > The described behavior is not depending on any option of the UpdateRequest, > so it does not make any difference if 'waitFlush', 'waitSearcher' or > 'softCommit' is true or false. > The described behavior makes the usage of ChildDocuments useless, because the > performance is unacceptable. > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14923) Indexing performance is unacceptable when child documents are involved
[ https://issues.apache.org/jira/browse/SOLR-14923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225901#comment-17225901 ] Thomas Wöckinger edited comment on SOLR-14923 at 11/4/20, 7:02 AM: --- [~dsmiley] Last investigations on this issue showed that flagging the UpdateLog to open a new RealTimeSearcher (as you mentionend at https://issues.apache.org/jira/browse/SOLR-12638?focusedCommentId=16872898&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16872898) seems to be the best solution. So i can start working on this, a question in advance: Would it be sufficient to track the document ids which require a reload and clear them on each openRealTimeSearcher call? Another question: What should be the result of to concurrent updates on the same document? I think it is the same as with normal atomic updates, and due the the fact the there is no rollback on transactions this can only be detected by versioning. was (Author: thomas.woeckinger): [~dsmiley] Last investigations on this issue showed that flagging the UpdateLog to open a new RealTimeSearcher (as you mentionend at https://issues.apache.org/jira/browse/SOLR-12638?focusedCommentId=16872898&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16872898) seems to be the best solution. So i can start working on this, a question in advance: Would it be sufficient to track the document ids which require a reload and clear them on each openRealTimeSearcher call? > Indexing performance is unacceptable when child documents are involved > -- > > Key: SOLR-14923 > URL: https://issues.apache.org/jira/browse/SOLR-14923 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: update, UpdateRequestProcessors >Affects Versions: master (9.0), 8.3, 8.4, 8.5, 8.6 >Reporter: Thomas Wöckinger >Priority: Critical > Labels: performance > > Parallel indexing does not make sense at moment when child documents are used. > The org.apache.solr.update.processor.DistributedUpdateProcessor checks at the > end of the method doVersionAdd if Ulog caches should be refreshed. > This check will return true if any child document is included in the > AddUpdateCommand. > If so ulog.openRealtimeSearcher(); is called, this call is very expensive, > and executed in a synchronized block of the UpdateLog instance, therefore all > other operations on the UpdateLog are blocked too. > Because every important UpdateLog method (add, delete, ...) is done using a > synchronized block almost each operation is blocked. > This reduces multi threaded index update to a single thread behavior. > The described behavior is not depending on any option of the UpdateRequest, > so it does not make any difference if 'waitFlush', 'waitSearcher' or > 'softCommit' is true or false. > The described behavior makes the usage of ChildDocuments useless, because the > performance is unacceptable. > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14977) Container plugins need a way to be configured
[
https://issues.apache.org/jira/browse/SOLR-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225848#comment-17225848
]
Noble Paul edited comment on SOLR-14977 at 11/4/20, 7:13 AM:
-
Let's have a simple interface as follows (change the name as you wish).
This will help us do a type-safe initialization of any plugin.
{code:java}
public interface SimplePlugin {
public void initPlugin(T initVals);
}
{code}
for instance the {{PlacementPluginConfig}} can have only the following
attributes
{code}
{
"myfirstString": "a text value",
"aLong": 50,
"aDoubleConfig": 3.1415928,
"shouldIStay": true}
{code}
It does not have to care about the attributes in {{PluginMeta}} if it does not
need it
was (Author: noble.paul):
Let's have a simple interface as follows (change the name as you wish).
This will help us do a type-safe initialization of any plugin.
{code:java}
public interface SimplePlugin {
public void initPlugin(T initVals);
}
{code}
> Container plugins need a way to be configured
> -
>
> Key: SOLR-14977
> URL: https://issues.apache.org/jira/browse/SOLR-14977
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Plugin system
>Reporter: Andrzej Bialecki
>Priority: Major
>
> Container plugins are defined in {{/clusterprops.json:/plugin}} using a
> simple {{PluginMeta}} bean. This is sufficient for implementations that don't
> need any configuration except for the {{pathPrefix}} but insufficient for
> anything else that needs more configuration parameters.
> An example would be a {{CollectionsRepairEventListener}} plugin proposed in
> PR-1962, which needs parameters such as the list of collections, {{waitFor}},
> maximum operations allowed, etc. to properly function.
> This issue proposes to extend the {{PluginMeta}} bean to allow a
> {{Map}} configuration parameters.
> There is an interface that we could potentially use ({{MapInitializedPlugin}}
> but it works only with {{String}} values. This is not optimal because it
> requires additional type-safety validation from the consumers. The existing
> {{PluginInfo}} / {{PluginInfoInitialized}} interface is too complex for this
> purpose.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14977) Container plugins need a way to be configured
[
https://issues.apache.org/jira/browse/SOLR-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225848#comment-17225848
]
Noble Paul edited comment on SOLR-14977 at 11/4/20, 7:18 AM:
-
Let's have a simple interface as follows (change the name as you wish).
This will help us do a type-safe initialization of any plugin.
{code:java}
public interface SimplePlugin {
public void initPlugin(T initVals);
}
{code}
for instance the {{PlacementPluginConfig}} can have only the following
attributes
{code:java}
{
"myfirstString": "a text value",
"aLong": 50,
"aDoubleConfig": 3.1415928,
"shouldIStay": true}
{code}
It does not have to care about the attributes in {{PluginMeta}} if it does not
need it
BTW I would prefer not to have something ugly like [this
|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cluster/placement/impl/PlacementPluginConfigImpl.java]|
Lets have something as follows
{code:java}
public class PlacementPluginConfig {
@JsonProperty
public String myfirstString;
@JsonProperty
public String aLong;
@JsonProperty
public String aDoubleConfig;
@JsonProperty
public String shouldIStay";
}
{code}
was (Author: noble.paul):
Let's have a simple interface as follows (change the name as you wish).
This will help us do a type-safe initialization of any plugin.
{code:java}
public interface SimplePlugin {
public void initPlugin(T initVals);
}
{code}
for instance the {{PlacementPluginConfig}} can have only the following
attributes
{code}
{
"myfirstString": "a text value",
"aLong": 50,
"aDoubleConfig": 3.1415928,
"shouldIStay": true}
{code}
It does not have to care about the attributes in {{PluginMeta}} if it does not
need it
> Container plugins need a way to be configured
> -
>
> Key: SOLR-14977
> URL: https://issues.apache.org/jira/browse/SOLR-14977
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Plugin system
>Reporter: Andrzej Bialecki
>Priority: Major
>
> Container plugins are defined in {{/clusterprops.json:/plugin}} using a
> simple {{PluginMeta}} bean. This is sufficient for implementations that don't
> need any configuration except for the {{pathPrefix}} but insufficient for
> anything else that needs more configuration parameters.
> An example would be a {{CollectionsRepairEventListener}} plugin proposed in
> PR-1962, which needs parameters such as the list of collections, {{waitFor}},
> maximum operations allowed, etc. to properly function.
> This issue proposes to extend the {{PluginMeta}} bean to allow a
> {{Map}} configuration parameters.
> There is an interface that we could potentially use ({{MapInitializedPlugin}}
> but it works only with {{String}} values. This is not optimal because it
> requires additional type-safety validation from the consumers. The existing
> {{PluginInfo}} / {{PluginInfoInitialized}} interface is too complex for this
> purpose.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14977) Container plugins need a way to be configured
[
https://issues.apache.org/jira/browse/SOLR-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225848#comment-17225848
]
Noble Paul edited comment on SOLR-14977 at 11/4/20, 7:23 AM:
-
Let's have a simple interface as follows (change the name as you wish).
This will help us do a type-safe initialization of any plugin.
{code:java}
public interface SimplePlugin {
public void initPlugin(T initVals);
}
{code}
for instance the {{PlacementPluginConfig}} can have only the following
attributes
{code:java}
{
"myfirstString": "a text value",
"aLong": 50,
"aDoubleConfig": 3.1415928,
"shouldIStay": true}
{code}
It does not have to care about the attributes in {{PluginMeta}} if it does not
need it
BTW I would prefer not to have something ugly like
[this|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cluster/placement/impl/PlacementPluginConfigImpl.java]
Lets have something as follows
{code:java}
public class PlacementPluginConfig {
@JsonProperty
public String myfirstString;
@JsonProperty
public String aLong;
@JsonProperty
public String aDoubleConfig;
@JsonProperty
public String shouldIStay";
}
{code}
was (Author: noble.paul):
Let's have a simple interface as follows (change the name as you wish).
This will help us do a type-safe initialization of any plugin.
{code:java}
public interface SimplePlugin {
public void initPlugin(T initVals);
}
{code}
for instance the {{PlacementPluginConfig}} can have only the following
attributes
{code:java}
{
"myfirstString": "a text value",
"aLong": 50,
"aDoubleConfig": 3.1415928,
"shouldIStay": true}
{code}
It does not have to care about the attributes in {{PluginMeta}} if it does not
need it
BTW I would prefer not to have something ugly like [this
|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cluster/placement/impl/PlacementPluginConfigImpl.java]|
Lets have something as follows
{code:java}
public class PlacementPluginConfig {
@JsonProperty
public String myfirstString;
@JsonProperty
public String aLong;
@JsonProperty
public String aDoubleConfig;
@JsonProperty
public String shouldIStay";
}
{code}
> Container plugins need a way to be configured
> -
>
> Key: SOLR-14977
> URL: https://issues.apache.org/jira/browse/SOLR-14977
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Plugin system
>Reporter: Andrzej Bialecki
>Priority: Major
>
> Container plugins are defined in {{/clusterprops.json:/plugin}} using a
> simple {{PluginMeta}} bean. This is sufficient for implementations that don't
> need any configuration except for the {{pathPrefix}} but insufficient for
> anything else that needs more configuration parameters.
> An example would be a {{CollectionsRepairEventListener}} plugin proposed in
> PR-1962, which needs parameters such as the list of collections, {{waitFor}},
> maximum operations allowed, etc. to properly function.
> This issue proposes to extend the {{PluginMeta}} bean to allow a
> {{Map}} configuration parameters.
> There is an interface that we could potentially use ({{MapInitializedPlugin}}
> but it works only with {{String}} values. This is not optimal because it
> requires additional type-safety validation from the consumers. The existing
> {{PluginInfo}} / {{PluginInfoInitialized}} interface is too complex for this
> purpose.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14977) Container plugins need a way to be configured
[
https://issues.apache.org/jira/browse/SOLR-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225848#comment-17225848
]
Noble Paul edited comment on SOLR-14977 at 11/4/20, 7:33 AM:
-
Let's have a simple interface as follows (change the name as you wish).
This will help us do a type-safe initialization of any plugin.
{code:java}
public interface SimplePlugin {
public void initPlugin(T initVals);
}
{code}
for instance the {{PlacementPluginConfig}} can have only the following
attributes
{code:java}
{
"myfirstString": "a text value",
"aLong": 50,
"aDoubleConfig": 3.1415928,
"shouldIStay": true}
{code}
It does not have to care about the attributes in {{PluginMeta}} if it does not
need it
BTW I would prefer not to have something ugly like
[this|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cluster/placement/impl/PlacementPluginConfigImpl.java]
Lets have something as follows
{code:java}
public class PlacementPluginConfig {
@JsonProperty
public String myfirstString;
@JsonProperty
public Long aLong;
@JsonProperty
public Double aDoubleConfig;
@JsonProperty
public Boolean shouldIStay";
}
{code}
was (Author: noble.paul):
Let's have a simple interface as follows (change the name as you wish).
This will help us do a type-safe initialization of any plugin.
{code:java}
public interface SimplePlugin {
public void initPlugin(T initVals);
}
{code}
for instance the {{PlacementPluginConfig}} can have only the following
attributes
{code:java}
{
"myfirstString": "a text value",
"aLong": 50,
"aDoubleConfig": 3.1415928,
"shouldIStay": true}
{code}
It does not have to care about the attributes in {{PluginMeta}} if it does not
need it
BTW I would prefer not to have something ugly like
[this|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cluster/placement/impl/PlacementPluginConfigImpl.java]
Lets have something as follows
{code:java}
public class PlacementPluginConfig {
@JsonProperty
public String myfirstString;
@JsonProperty
public String aLong;
@JsonProperty
public String aDoubleConfig;
@JsonProperty
public String shouldIStay";
}
{code}
> Container plugins need a way to be configured
> -
>
> Key: SOLR-14977
> URL: https://issues.apache.org/jira/browse/SOLR-14977
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Plugin system
>Reporter: Andrzej Bialecki
>Priority: Major
>
> Container plugins are defined in {{/clusterprops.json:/plugin}} using a
> simple {{PluginMeta}} bean. This is sufficient for implementations that don't
> need any configuration except for the {{pathPrefix}} but insufficient for
> anything else that needs more configuration parameters.
> An example would be a {{CollectionsRepairEventListener}} plugin proposed in
> PR-1962, which needs parameters such as the list of collections, {{waitFor}},
> maximum operations allowed, etc. to properly function.
> This issue proposes to extend the {{PluginMeta}} bean to allow a
> {{Map}} configuration parameters.
> There is an interface that we could potentially use ({{MapInitializedPlugin}}
> but it works only with {{String}} values. This is not optimal because it
> requires additional type-safety validation from the consumers. The existing
> {{PluginInfo}} / {{PluginInfoInitialized}} interface is too complex for this
> purpose.
--
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
