[GitHub] [lucene-solr] noblepaul commented on issue #1116: SOLR-14135: Utils.toJavabin returns a byte[] instead of InputStream

[GitBox]

noblepaul commented on issue #1116: SOLR-14135: Utils.toJavabin returns a 
byte[] instead of InputStream
URL: https://github.com/apache/lucene-solr/pull/1116#issuecomment-568863673
 
 
   You can create another method with the appropriate return type, correct?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1109: More pervasive use of PackageLoader / PluginInfo

[GitBox]

noblepaul commented on a change in pull request #1109: More pervasive use of 
PackageLoader / PluginInfo
URL: https://github.com/apache/lucene-solr/pull/1109#discussion_r361278515
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/schema/IndexSchemaFactory.java
 ##
 @@ -62,7 +62,7 @@ public static IndexSchema buildIndexSchema(String 
resourceName, SolrConfig confi
 PluginInfo info = config.getPluginInfo(IndexSchemaFactory.class.getName());
 IndexSchemaFactory factory;
 if (null != info) {
-  factory = config.getResourceLoader().newInstance(info.className, 
IndexSchemaFactory.class);
+  factory = config.getResourceLoader().newInstance(info, 
IndexSchemaFactory.class);
 
 Review comment:
   That's plain wrong. SRL has no idea which version of package should be loaded


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-13101) Shared storage support in SolrCloud

[Ishan Chattopadhyaya (Jira)]

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

Ishan Chattopadhyaya commented on SOLR-13101:
-

Sorry, haven't looked into the branch yet.
bq. Yes, the fundamentals (the new SHARED replica type) need to be in core. 
Specific storage options (such as S3) are already designed to be pluggable.
This means that the fundamentals stay in solr-core and the specific pluggable 
storage options go into separate modules (contribs?), right?

If that's the case, would it be possible (for easier reviewing) to please split 
this up into two separate PRs, i.e. one for the solr-core changes, and another 
PR for the separate modules?

> Shared storage support in SolrCloud
> ---
>
> Key: SOLR-13101
> URL: https://issues.apache.org/jira/browse/SOLR-13101
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Yonik Seeley
>Priority: Major
>  Time Spent: 8h 10m
>  Remaining Estimate: 0h
>
> Solr should have first-class support for shared storage (blob/object stores 
> like S3, google cloud storage, etc. and shared filesystems like HDFS, NFS, 
> etc).
> The key component will likely be a new replica type for shared storage.  It 
> would have many of the benefits of the current "pull" replicas (not indexing 
> on all replicas, all shards identical with no shards getting out-of-sync, 
> etc), but would have additional benefits:
>  - Any shard could become leader (the blob store always has the index)
>  - Better elasticity scaling down
>- durability not linked to number of replcias.. a single replica could be 
> common for write workloads
>- could drop to 0 replicas for a shard when not needed (blob store always 
> has index)
>  - Allow for higher performance write workloads by skipping the transaction 
> log
>- don't pay for what you don't need
>- a commit will be necessary to flush to stable storage (blob store)
>  - A lot of the complexity and failure modes go away
> An additional component a Directory implementation that will work well with 
> blob stores.  We probably want one that treats local disk as a cache since 
> the latency to remote storage is so large.  I think there are still some 
> "locking" issues to be solved here (ensuring that more than one writer to the 
> same index won't corrupt it).  This should probably be pulled out into a 
> different JIRA 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

[GitHub] [lucene-solr] a-siuniaev opened a new pull request #1122: SOLR-12490 Added parsing of json.queries for referring in JSON facets

[GitBox]

a-siuniaev opened a new pull request #1122: SOLR-12490 Added parsing of 
json.queries for referring in JSON facets
URL: https://github.com/apache/lucene-solr/pull/1122
 
 
   # Description
   
   Added DSL support for queries - to have the ability to refer from 
domain.filter. It supports both single and multi-value query parameters. 
Support forexclusion is not yet implemented.
   
   # Solution
   
   Intoduced json.queries field, which is translated with query DSL (see 
[comment](https://issues.apache.org/jira/browse/SOLR-12490?focusedCommentId=16514420&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16514420)).
   
   # Checklist
   
   - [+] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [+] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [+] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [+] I have developed this patch against the `master` branch.
   - [+] I have run `ant precommit` and the appropriate test suite.
   - [+] I have added tests for my changes.
   - [ ] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-13778) Windows JDK SSL Test Failure trend: SSLException: Software caused connection abort: recv failed

[Dawid Weiss (Jira)]

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

Dawid Weiss commented on SOLR-13778:


Thanks Uwe!

> Windows JDK SSL Test Failure trend: SSLException: Software caused connection 
> abort: recv failed
> ---
>
> Key: SOLR-13778
> URL: https://issues.apache.org/jira/browse/SOLR-13778
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: RecvFailedTest.java, dumps-LegacyCloud.zip, 
> logs-2019-12-12-1.zip, recv-multiple-2019-12-18.zip
>
>
> Now that Uwe's jenkins build has been correctly reporting it's build results 
> for my [automated 
> reports|http://fucit.org/solr-jenkins-reports/failure-report.html] to pick 
> up, I've noticed a pattern of failures that indicate a definite problem with 
> using SSL on Windows (even with java 11.0.4
>  )
>  The symptommatic stack traces all contain...
> {noformat}
> ...
>[junit4]> Caused by: javax.net.ssl.SSLException: Software caused 
> connection abort: recv failed
>[junit4]>at 
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
> ...
>[junit4]> Caused by: java.net.SocketException: Software caused 
> connection abort: recv failed
>[junit4]>at 
> java.base/java.net.SocketInputStream.socketRead0(Native Method)
> ...
> {noformat}
> I suspect this may be related to 
> [https://bugs.openjdk.java.net/browse/JDK-8209333] but i have no concrete 
> evidence to back this up.
> I'll post some details of my analysis in comments...



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

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

[GitHub] [lucene-solr] uschindler merged pull request #1114: LUCENE-9109: Use stack walker to implement TestSecurityManager's detection of test JVM exit

[GitBox]

uschindler merged pull request #1114: LUCENE-9109: Use stack walker to 
implement TestSecurityManager's detection of test JVM exit
URL: https://github.com/apache/lucene-solr/pull/1114
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (LUCENE-9109) Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM exit

[ASF subversion and git services (Jira)]

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

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

Commit 65611f6d662ced3acaea2bd6fa8c15404b28a3bf in lucene-solr's branch 
refs/heads/master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=65611f6 ]

LUCENE-9109: Use stack walker to implement TestSecurityManager's detection of 
JVM exit (#1114)

Use stack walker (Java 11 on master only) to implement TestSecurityManager's 
detection of test JVM exit

> Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM 
> exit
> 
>
> Key: LUCENE-9109
> URL: https://issues.apache.org/jira/browse/LUCENE-9109
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/test-framework
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This is just a small improvement in Lucene/Solr master (Java 11) to detect 
> exit of JVM in our test framework. There are other places in Lucene that use 
> ineffective ways to inspect the stack trace.
> This one optimizes the implementation of 
> TestSecurityManager#checkExit(status) to disallow all JVM exits outside of 
> the official test runner by using StackWalker. In addition this needs no 
> additional permissions, because we do not instruct StackWalker to fetch all 
> crazy stuff like Class instances of stack elements.
> The way how this works is: Walk through stack trace:
> - skip all internal frames (those which come before the actual exit call)
> - skip all frmes with the actual exit call
> - limit to one more frame (the method calling System.exit())
> - check if that remaining frame is on our whitelist
> This can only be commited to master (9.0), as it requires Java 9.



--
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-13984) Solr should run inside a SecurityManager

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-13984:


Commit efd13f2884d55d67d73dca771fa9a2a20ae3d6ee in lucene-solr's branch 
refs/heads/gradle-master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=efd13f2 ]

SOLR-13984: docs, changes.txt


> Solr should run inside a SecurityManager
> 
>
> Key: SOLR-13984
> URL: https://issues.apache.org/jira/browse/SOLR-13984
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Robert Muir
>Priority: Major
> Fix For: 8.5
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> To reduce the effect of attacks, esp. RCE, Solr should run inside a 
> SecurityManager.
> Quoting Uwe here:
> {quote}
> The correct way to fix all issues we have seen the last time is very simple: 
> LET'S RUN SOLR INSIDE A SECURITY MANAGER IN PRODUCTION (like in tests). 
> Elasticsearch is doing this, so please please let's do this instead. But this 
> requires to finally get rid of the webapplication and start.jar and add our 
> own bootstrapping (like in tests) that configure Jetty and Security Manager 
> from our own org.apache.solr.bootstrap.Main.java (or similar).
> {quote}
> https://jira.apache.org/jira/browse/SOLR-12316?focusedCommentId=16465038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16465038



--
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-9109) Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM exit

[ASF subversion and git services (Jira)]

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

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

Commit 65611f6d662ced3acaea2bd6fa8c15404b28a3bf in lucene-solr's branch 
refs/heads/gradle-master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=65611f6 ]

LUCENE-9109: Use stack walker to implement TestSecurityManager's detection of 
JVM exit (#1114)

Use stack walker (Java 11 on master only) to implement TestSecurityManager's 
detection of test JVM exit

> Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM 
> exit
> 
>
> Key: LUCENE-9109
> URL: https://issues.apache.org/jira/browse/LUCENE-9109
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/test-framework
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This is just a small improvement in Lucene/Solr master (Java 11) to detect 
> exit of JVM in our test framework. There are other places in Lucene that use 
> ineffective ways to inspect the stack trace.
> This one optimizes the implementation of 
> TestSecurityManager#checkExit(status) to disallow all JVM exits outside of 
> the official test runner by using StackWalker. In addition this needs no 
> additional permissions, because we do not instruct StackWalker to fetch all 
> crazy stuff like Class instances of stack elements.
> The way how this works is: Walk through stack trace:
> - skip all internal frames (those which come before the actual exit call)
> - skip all frmes with the actual exit call
> - limit to one more frame (the method calling System.exit())
> - check if that remaining frame is on our whitelist
> This can only be commited to master (9.0), as it requires Java 9.



--
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-14120) Solr Admin UI breaks when using IE 11

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14120:


Commit 3ab59aa1c910d71239d3fbfed05dcb30aca616b5 in lucene-solr's branch 
refs/heads/gradle-master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3ab59aa ]

SOLR-14120: Solr Admin UI breaks when using IE11


> Solr Admin UI breaks when using IE 11
> -
>
> Key: SOLR-14120
> URL: https://issues.apache.org/jira/browse/SOLR-14120
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (9.0), 8.3.1
> Environment: Operation System: Microsoft Windows 10 Enterprise 
> (German)
> Version: 10.0.17763 Build 17763
> Browser: Internet Explorer 11
> Version: 11.864.17763
> Update: 11.0.160
>Reporter: Jakob Furrer
>Assignee: Robert Muir
>Priority: Minor
> Fix For: 8.5
>
> Attachments: SOLR-14120.patch, SOLR-14120.patch, SOLR-14120.patch, 
> Solr-8.3.1_ IE11_AdminUI_Error.png
>
>
> A customer of mine is restricted to use no other browser than Internet 
> Explorer to access the Solr Administration User Interface.
> He reported that the website does not display any content in the main area 
> when any button of the menu on the left hand side is clicked.
> I can replicate that behavior on my machine.
> Symptoms
> -
> When the Admin UI is loaded, the menu on the left hand side is visible but no 
> content is ever displayed in the main area.
> Any menu item (e.g. "Dashboard", "logging", "Java Properties" etc.) can be 
> clicked but no content appears.
> An error with a stacktrace is shown in the JavaScript console.
> History
> -
> I can confirm, that some month ago the Admin UI worked well under IE.
> However, I have not researched with what update of IE the problems exactly 
> started.
> Analysis
> -
> The displayed stacktrace indicates that Internet Explorer does not support 
> the method "startsWith" (and subsequently, the same is true for the method 
> "includes").
> This behavior is documented:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/startsWith#Browser_compatibility
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes#Browser_compatibility
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/includes#Browser_compatibility



--
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-14146) Zookeeper version not resolved in RefGuide

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14146:


Commit aa43f352d9103b51c0cf33fd41bf16192810627f in lucene-solr's branch 
refs/heads/gradle-master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=aa43f35 ]

SOLR-14146: Zookeeper version not resolved in RefGuide (#1119)



> Zookeeper version not resolved in RefGuide
> --
>
> Key: SOLR-14146
> URL: https://issues.apache.org/jira/browse/SOLR-14146
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 8.3.1
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.4
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Check the page 
> [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper]
> It prints literal version string instead of the actual zookeeper version 
> number.



--
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-14143) Add request-logging to securing solr page

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14143:


Commit b87e1f5843f163ab5d8a90c6b0dc0f95f6e932fc in lucene-solr's branch 
refs/heads/gradle-master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b87e1f5 ]

SOLR-14143: add request logging to securing solr page


> Add request-logging to securing solr page
> -
>
> Key: SOLR-14143
> URL: https://issues.apache.org/jira/browse/SOLR-14143
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-14143.patch
>
>
> This functionality was cleaned up in SOLR-14138 and for a major release I've 
> proposed to turn it on by default in SOLR-14142.
> But for now, I think the "securing solr" page should instruct how to turn 
> this on. Hopefully if we fix the default in SOLR-14142, this paragraph can 
> simply go away (I think it is expert to not want to log such a basic thing).
> There is some overlap with "audit logging", but for sure the request log is 
> always more complete, since it logs things that never even make it to solr 
> (as well as 4xx denied by solr itself, of course). You can see the differenes 
> by running a simple nmap script scan of your solr instance or similar.



--
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-14144) add IP-based access control to securing solr page

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14144:


Commit b73e27d1ca20eebc2c5a2acd2d58bce0f64e8cb0 in lucene-solr's branch 
refs/heads/gradle-master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b73e27d ]

SOLR-14144: add IP-based access control to securing solr page


> add IP-based access control to securing solr page
> -
>
> Key: SOLR-14144
> URL: https://issues.apache.org/jira/browse/SOLR-14144
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-14144.patch
>
>
> This is an easy way to improve security. See SOLR-14136
> By default, access is allowed to all addresses, but if someone specifies a 
> simple configuration to only allow local access and their own servers, such 
> as:
> SOLR_IP_WHITELIST="127.0.0.1, [::1], 192.168.0.0/24, [2000:123:4:5::]/64"
> , then with a simple one-liner, things are a lot better than being open to 
> everyone. Let's add something short and sweet to the ref guide security page.



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

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

[jira] [Created] (LUCENE-9111) Frequent JVM failures on IdealLoopTree::est_loop_flow_merge_sz() (VM 14-ea+27-1339)

[Dawid Weiss (Jira)]

Dawid Weiss created LUCENE-9111:
---

 Summary: Frequent JVM failures on 
IdealLoopTree::est_loop_flow_merge_sz()  (VM 14-ea+27-1339)
 Key: LUCENE-9111
 URL: https://issues.apache.org/jira/browse/LUCENE-9111
 Project: Lucene - Core
  Issue Type: Task
Reporter: Dawid Weiss


Plenty of these recently
{code}
JRE version: OpenJDK Runtime Environment (14.0+27) (build 14-ea+27-1339)
{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] [Updated] (LUCENE-9111) Frequent JVM failures on IdealLoopTree::est_loop_flow_merge_sz() (VM 14-ea+27-1339)

[Dawid Weiss (Jira)]

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

Dawid Weiss updated LUCENE-9111:

Description: 
Plenty of these recently
{code}
JRE version: OpenJDK Runtime Environment (14.0+27) (build 14-ea+27-1339)
{code}

{code}
#
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0x7f273279b5a8, pid=7285, tid=10064
   [junit4] #
   [junit4] # JRE version: OpenJDK Runtime Environment (14.0+27) (build 
14-ea+27-1339)
   [junit4] # Java VM: OpenJDK 64-Bit Server VM (14-ea+27-1339, mixed mode, 
tiered, z gc, linux-amd64)
   [junit4] # Problematic frame:
   [junit4] # V  [libjvm.so+0x9d85a8]  IdealLoopTree::est_loop_flow_merge_sz() 
const+0x158
{code}

  was:
Plenty of these recently
{code}
JRE version: OpenJDK Runtime Environment (14.0+27) (build 14-ea+27-1339)
{code}


> Frequent JVM failures on IdealLoopTree::est_loop_flow_merge_sz()  (VM 
> 14-ea+27-1339)
> 
>
> Key: LUCENE-9111
> URL: https://issues.apache.org/jira/browse/LUCENE-9111
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Major
>
> Plenty of these recently
> {code}
> JRE version: OpenJDK Runtime Environment (14.0+27) (build 14-ea+27-1339)
> {code}
> {code}
> #
>[junit4] # A fatal error has been detected by the Java Runtime Environment:
>[junit4] #
>[junit4] #  SIGSEGV (0xb) at pc=0x7f273279b5a8, pid=7285, tid=10064
>[junit4] #
>[junit4] # JRE version: OpenJDK Runtime Environment (14.0+27) (build 
> 14-ea+27-1339)
>[junit4] # Java VM: OpenJDK 64-Bit Server VM (14-ea+27-1339, mixed mode, 
> tiered, z gc, linux-amd64)
>[junit4] # Problematic frame:
>[junit4] # V  [libjvm.so+0x9d85a8]  
> IdealLoopTree::est_loop_flow_merge_sz() const+0x158
> {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-9109) Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM exit

[ASF subversion and git services (Jira)]

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

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

Commit 982797e23fcde6f11491e849ba4405d90b3fbfac in lucene-solr's branch 
refs/heads/branch_8x from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=982797e ]

LUCENE-9109: Backport some changes from master (except StackWalker) to improve 
TestSecurityManager


> Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM 
> exit
> 
>
> Key: LUCENE-9109
> URL: https://issues.apache.org/jira/browse/LUCENE-9109
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/test-framework
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This is just a small improvement in Lucene/Solr master (Java 11) to detect 
> exit of JVM in our test framework. There are other places in Lucene that use 
> ineffective ways to inspect the stack trace.
> This one optimizes the implementation of 
> TestSecurityManager#checkExit(status) to disallow all JVM exits outside of 
> the official test runner by using StackWalker. In addition this needs no 
> additional permissions, because we do not instruct StackWalker to fetch all 
> crazy stuff like Class instances of stack elements.
> The way how this works is: Walk through stack trace:
> - skip all internal frames (those which come before the actual exit call)
> - skip all frmes with the actual exit call
> - limit to one more frame (the method calling System.exit())
> - check if that remaining frame is on our whitelist
> This can only be commited to master (9.0), as it requires Java 9.



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

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

[jira] [Comment Edited] (LUCENE-9109) Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM exit

[Uwe Schindler (Jira)]

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

Uwe Schindler edited comment on LUCENE-9109 at 12/25/19 12:53 PM:
--

I backported the removal of SecurityManager to 8.x.

I wanted to refactor the code and use the same stream logic like with 
StackWalker, but this was impossible as Java 8 does not support 
{{Stream#dropWhile()}} and {{Predicate#not()}}. So I left the main logic as is 
in 8.x.


was (Author: thetaphi):
I backported the removal of SecurityManager to 8.x.

I wanted to refaczor the code and use the same stream logic like with 
StackWalker, but this was impossible as Java 8 does not support 
{{Stream#dropWhile()}} and {{Predicate#not()}}. So I left the main logic as is 
in 8.x.

> Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM 
> exit
> 
>
> Key: LUCENE-9109
> URL: https://issues.apache.org/jira/browse/LUCENE-9109
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/test-framework
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This is just a small improvement in Lucene/Solr master (Java 11) to detect 
> exit of JVM in our test framework. There are other places in Lucene that use 
> ineffective ways to inspect the stack trace.
> This one optimizes the implementation of 
> TestSecurityManager#checkExit(status) to disallow all JVM exits outside of 
> the official test runner by using StackWalker. In addition this needs no 
> additional permissions, because we do not instruct StackWalker to fetch all 
> crazy stuff like Class instances of stack elements.
> The way how this works is: Walk through stack trace:
> - skip all internal frames (those which come before the actual exit call)
> - skip all frmes with the actual exit call
> - limit to one more frame (the method calling System.exit())
> - check if that remaining frame is on our whitelist
> This can only be commited to master (9.0), as it requires Java 9.



--
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-9109) Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM exit

[Uwe Schindler (Jira)]

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

Uwe Schindler resolved LUCENE-9109.
---
Resolution: Fixed

> Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM 
> exit
> 
>
> Key: LUCENE-9109
> URL: https://issues.apache.org/jira/browse/LUCENE-9109
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/test-framework
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This is just a small improvement in Lucene/Solr master (Java 11) to detect 
> exit of JVM in our test framework. There are other places in Lucene that use 
> ineffective ways to inspect the stack trace.
> This one optimizes the implementation of 
> TestSecurityManager#checkExit(status) to disallow all JVM exits outside of 
> the official test runner by using StackWalker. In addition this needs no 
> additional permissions, because we do not instruct StackWalker to fetch all 
> crazy stuff like Class instances of stack elements.
> The way how this works is: Walk through stack trace:
> - skip all internal frames (those which come before the actual exit call)
> - skip all frmes with the actual exit call
> - limit to one more frame (the method calling System.exit())
> - check if that remaining frame is on our whitelist
> This can only be commited to master (9.0), as it requires Java 9.



--
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-9109) Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM exit

[Uwe Schindler (Jira)]

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

Uwe Schindler commented on LUCENE-9109:
---

I backported the removal of SecurityManager to 8.x.

I wanted to refaczor the code and use the same stream logic like with 
StackWalker, but this was impossible as Java 8 does not support 
{{Stream#dropWhile()}} and {{Predicate#not()}}. So I left the main logic as is 
in 8.x.

> Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM 
> exit
> 
>
> Key: LUCENE-9109
> URL: https://issues.apache.org/jira/browse/LUCENE-9109
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/test-framework
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This is just a small improvement in Lucene/Solr master (Java 11) to detect 
> exit of JVM in our test framework. There are other places in Lucene that use 
> ineffective ways to inspect the stack trace.
> This one optimizes the implementation of 
> TestSecurityManager#checkExit(status) to disallow all JVM exits outside of 
> the official test runner by using StackWalker. In addition this needs no 
> additional permissions, because we do not instruct StackWalker to fetch all 
> crazy stuff like Class instances of stack elements.
> The way how this works is: Walk through stack trace:
> - skip all internal frames (those which come before the actual exit call)
> - skip all frmes with the actual exit call
> - limit to one more frame (the method calling System.exit())
> - check if that remaining frame is on our whitelist
> This can only be commited to master (9.0), as it requires Java 9.



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

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

[jira] [Comment Edited] (LUCENE-9109) Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM exit

[Uwe Schindler (Jira)]

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

Uwe Schindler edited comment on LUCENE-9109 at 12/25/19 2:09 PM:
-

I backported the removal of AccessController to 8.x.

I wanted to refactor the code and use the same stream logic like with 
StackWalker, but this was impossible as Java 8 does not support 
{{Stream#dropWhile()}} and {{Predicate#not()}}. So I left the main logic as is 
in 8.x.


was (Author: thetaphi):
I backported the removal of SecurityManager to 8.x.

I wanted to refactor the code and use the same stream logic like with 
StackWalker, but this was impossible as Java 8 does not support 
{{Stream#dropWhile()}} and {{Predicate#not()}}. So I left the main logic as is 
in 8.x.

> Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM 
> exit
> 
>
> Key: LUCENE-9109
> URL: https://issues.apache.org/jira/browse/LUCENE-9109
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/test-framework
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This is just a small improvement in Lucene/Solr master (Java 11) to detect 
> exit of JVM in our test framework. There are other places in Lucene that use 
> ineffective ways to inspect the stack trace.
> This one optimizes the implementation of 
> TestSecurityManager#checkExit(status) to disallow all JVM exits outside of 
> the official test runner by using StackWalker. In addition this needs no 
> additional permissions, because we do not instruct StackWalker to fetch all 
> crazy stuff like Class instances of stack elements.
> The way how this works is: Walk through stack trace:
> - skip all internal frames (those which come before the actual exit call)
> - skip all frmes with the actual exit call
> - limit to one more frame (the method calling System.exit())
> - check if that remaining frame is on our whitelist
> This can only be commited to master (9.0), as it requires Java 9.



--
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-9111) Frequent JVM failures on IdealLoopTree::est_loop_flow_merge_sz() (VM 14-ea+27-1339)

[Uwe Schindler (Jira)]

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

Uwe Schindler commented on LUCENE-9111:
---

Known issue, already in progress: 
https://bugs.openjdk.java.net/browse/JDK-8236412, 
https://bugs.openjdk.java.net/browse/JDK-8235870, 
https://bugs.openjdk.java.net/browse/JDK-8235984

> Frequent JVM failures on IdealLoopTree::est_loop_flow_merge_sz()  (VM 
> 14-ea+27-1339)
> 
>
> Key: LUCENE-9111
> URL: https://issues.apache.org/jira/browse/LUCENE-9111
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Major
>
> Plenty of these recently
> {code}
> JRE version: OpenJDK Runtime Environment (14.0+27) (build 14-ea+27-1339)
> {code}
> {code}
> #
>[junit4] # A fatal error has been detected by the Java Runtime Environment:
>[junit4] #
>[junit4] #  SIGSEGV (0xb) at pc=0x7f273279b5a8, pid=7285, tid=10064
>[junit4] #
>[junit4] # JRE version: OpenJDK Runtime Environment (14.0+27) (build 
> 14-ea+27-1339)
>[junit4] # Java VM: OpenJDK 64-Bit Server VM (14-ea+27-1339, mixed mode, 
> tiered, z gc, linux-amd64)
>[junit4] # Problematic frame:
>[junit4] # V  [libjvm.so+0x9d85a8]  
> IdealLoopTree::est_loop_flow_merge_sz() const+0x158
> {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] [Resolved] (LUCENE-9111) Frequent JVM failures on IdealLoopTree::est_loop_flow_merge_sz() (VM 14-ea+27-1339)

[Dawid Weiss (Jira)]

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

Dawid Weiss resolved LUCENE-9111.
-
Resolution: Duplicate

> Frequent JVM failures on IdealLoopTree::est_loop_flow_merge_sz()  (VM 
> 14-ea+27-1339)
> 
>
> Key: LUCENE-9111
> URL: https://issues.apache.org/jira/browse/LUCENE-9111
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Major
>
> Plenty of these recently
> {code}
> JRE version: OpenJDK Runtime Environment (14.0+27) (build 14-ea+27-1339)
> {code}
> {code}
> #
>[junit4] # A fatal error has been detected by the Java Runtime Environment:
>[junit4] #
>[junit4] #  SIGSEGV (0xb) at pc=0x7f273279b5a8, pid=7285, tid=10064
>[junit4] #
>[junit4] # JRE version: OpenJDK Runtime Environment (14.0+27) (build 
> 14-ea+27-1339)
>[junit4] # Java VM: OpenJDK 64-Bit Server VM (14-ea+27-1339, mixed mode, 
> tiered, z gc, linux-amd64)
>[junit4] # Problematic frame:
>[junit4] # V  [libjvm.so+0x9d85a8]  
> IdealLoopTree::est_loop_flow_merge_sz() const+0x158
> {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-14149) Remove non-changes from CHANGES.txt

[Erick Erickson (Jira)]

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

Erick Erickson commented on SOLR-14149:
---

bq. The layout of the distribution is documented in solr/README.txt

Right, and it says:
server/
  A self-contained Solr instance, complete with a sample
  configuration and documents to index. Please see: bin/solr start -help
  for more information about starting a Solr server.

And under that we have
./solr-webapp/webapp/WEB-INF/lib/
./lib

and at least copies of these in each.

jetty-http-9.4.19.v20190610.jar
jetty-util-9.4.19.v20190610.jar
jetty-io-9.4.19.v20190610.jar

We have no guidance there about _why_ someone would care about what's in which 
directory. Fortunately it "just works".

Here's the comment about the dist directory:

dist/solr--XX.jar
  The Apache Solr libraries.  To compile Apache Solr Plugins,
  one or more of these will be required.  The core library is
  required at a minimum. (see http://wiki.apache.org/solr/SolrPlugins
  for more information).

But no mention of dist/solrj-lib, which is necessary for anyone compiling, say, 
an external indexing program (which we recommend in other places).

Anyway, I doubt it's worth much more debate, probably well to revisit this 
sometime after the Gradle build becomes a reality.

> Remove non-changes from CHANGES.txt
> ---
>
> Key: SOLR-14149
> URL: https://issues.apache.org/jira/browse/SOLR-14149
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>
> Our CHANGES.txt should just list our changes / release notes.  Nothing else.
> * no Introduction
> * no "Getting Started"
> * no "Versions of Major Components" with each release.
> We have a website, a reference guide, and a README.md that are all more 
> suitable places.  Lets not maintain it here as well; lets keep this file 
> focused on it's namesake.  We can/should *link* to that information from 
> CHANGES.txt.  For example linking to 
> https://lucene.apache.org/solr/guide/8_4/solr-upgrade-notes.html is highly 
> appropriate as it's a more user friendly editorialized version of CHANGES.txt.



--
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-14149) Remove non-changes from CHANGES.txt

[David Smiley (Jira)]

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

David Smiley commented on SOLR-14149:
-

Hey; improve away on that as you wish :-)  I confess I don't care much about 
that matter.  I just want to focus on with the issue title & description say.

> Remove non-changes from CHANGES.txt
> ---
>
> Key: SOLR-14149
> URL: https://issues.apache.org/jira/browse/SOLR-14149
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>
> Our CHANGES.txt should just list our changes / release notes.  Nothing else.
> * no Introduction
> * no "Getting Started"
> * no "Versions of Major Components" with each release.
> We have a website, a reference guide, and a README.md that are all more 
> suitable places.  Lets not maintain it here as well; lets keep this file 
> focused on it's namesake.  We can/should *link* to that information from 
> CHANGES.txt.  For example linking to 
> https://lucene.apache.org/solr/guide/8_4/solr-upgrade-notes.html is highly 
> appropriate as it's a more user friendly editorialized version of CHANGES.txt.



--
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] Traktormaster opened a new pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left

[GitBox]

Traktormaster opened a new pull request #1123: LUCENE-9093: Unified highlighter 
with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123
 
 
   # Description
   
   This is an improved version of the patch submitted to the Jira issue about a 
week ago. A lot of information and discussion was posted on Jira. Here are my 
relevant comments:
   [Initial comment about possible 
solution](https://issues.apache.org/jira/browse/LUCENE-9093?focusedCommentId=16995738&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16995738)
   [Follow-up with more 
details](https://issues.apache.org/jira/browse/LUCENE-9093?focusedCommentId=16996736&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16996736)
   
   # Solution
   [Submitted patch and some notes on the 
implementation](https://issues.apache.org/jira/browse/LUCENE-9093?focusedCommentId=16998660&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16998660)
   
   This pull request is made so that the new parameter's default value is 
backward-compatible when merging to the 8.x and 7.x branches.
   @dsmiley suggested that for the 9.x (master) branch this should be changed 
in a second PR. In this 2nd phase I'll create another PR here with a 
`hl.fragalign` of `0.5` and updated docs. Regarding this 2nd PR I'd also 
suggest to change the default `hl.bs.type` to `WORD` as the new behavior will 
then be similar to the other highlighters' default behavior.
   
   # Tests
   All related tests were updated and extended with a few new assertions to 
check the changes. I wrote one more comment clarifying how the changes work 
with different BreakIterator types:
   [Clarification on how SENTENCE BI will 
behave](https://issues.apache.org/jira/browse/LUCENE-9093?focusedCommentId=17002548&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17002548)
   
   # 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.
   - [x] I have run `ant precommit` and the appropriate test suite.
   - [x] 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


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets

[Mikhail Khludnev (Jira)]

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

Mikhail Khludnev commented on SOLR-12490:
-

[https://github.com/apache/lucene-solr/pull/1122]

> Query DSL supports for further referring and exclusion in JSON facets 
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
>  Issue Type: Improvement
>  Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
>  Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch, 
> image-2019-10-21-09-37-37-118.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It's spin off from the 
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>  
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like 
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998 
>
> # but we can refer only separate params in {{domain.filter}}, it's not 
> possible to refer separate clauses
> see the first comment



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

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

[GitHub] [lucene-solr] uschindler commented on issue #1120: LUCENE-9110: Switch tests to use StackWalker

[GitBox]

uschindler commented on issue #1120: LUCENE-9110: Switch tests to use 
StackWalker
URL: https://github.com/apache/lucene-solr/pull/1120#issuecomment-568923838
 
 
   I removed the remaining 4 tests that required the full stack trace and 
rewrote them to use the new methods. I don't care of requesting a StackWalker 2 
or 3 times as the code gets much cleaner. It should be faster anyways. And 
debugging shows that the stack trace is requested very seldom.
   
   I think we are close to put getStackTrace() or forbiddenapis.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] dweiss commented on issue #1121: SOLR-11207: Add OWASP dependency checker to gradle build

[GitBox]

dweiss commented on issue #1121: SOLR-11207: Add OWASP dependency checker to 
gradle build
URL: https://github.com/apache/lucene-solr/pull/1121#issuecomment-568923921
 
 
   This looks good to me, Jan. The only question is whether we want to include 
it now or later -- the dependencies is something still being worked on?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] janhoy commented on issue #1121: SOLR-11207: Add OWASP dependency checker to gradle build

[GitBox]

janhoy commented on issue #1121: SOLR-11207: Add OWASP dependency checker to 
gradle build
URL: https://github.com/apache/lucene-solr/pull/1121#issuecomment-568924313
 
 
   Sure, we can include it closer to master merge.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Comment Edited] (SOLR-14137) Boosting by date (and perhaps others) shows a steady decline 6.6->8.3

[Erick Erickson (Jira)]

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

Erick Erickson edited comment on SOLR-14137 at 12/25/19 7:21 PM:
-

This is a more tightly controlled set of tests. All the indexes are much closer 
to being uniform, see second_run.png. 

By "uniform" I mean:

- The numeric values should be identical across the indexes I generated because 
I used the same random seed

- I bumped the ramBuferSizeMB to 500 and used NoMergePolicy to create the 
index, so any differences between indexes should be minimal.

- The random words chosen for the text may still differ though, I missed that. 
But the results are consistent enough that I'm not going to stress over that 
unless I decide to run them all again.

The results are quite consistent with my earlier run. Note that 6.6.1 and 7.1 
are quite similar, with the biggest jump happening between 7.1 and 7.7.2. 
7.7.2->8.3.1 shows an additional decline.



was (Author: erickerickson):
This is a more tightly controlled set of tests. All the indexes are much closer 
to being uniform. By "uniform" I mean:

- The numeric values should be identical across the indexes I generated because 
I used the same random seed

- I bumped the ramBuferSizeMB to 500 and used NoMergePolicy to create the 
index, so any differences between indexes should be minimal.

- The random words chosen for the text may still differ though, I missed that. 
But the results are consistent enough that I'm not going to stress over that 
unless I decide to run them all again.

The results are quite consistent with my earlier run. Note that 6.6.1 and 7.1 
are quite similar, with the biggest jump happening between 7.1 and 7.7.2. 
7.7.2->8.3.1 shows an additional decline.


> Boosting by date (and perhaps others) shows a steady decline 6.6->8.3
> -
>
> Key: SOLR-14137
> URL: https://issues.apache.org/jira/browse/SOLR-14137
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Priority: Major
> Attachments: Screen Shot 2019-12-19 at 2.35.41 PM.png, Screen Shot 
> 2019-12-19 at 3.09.37 PM.png, Screen Shot 2019-12-19 at 3.31.16 PM.png, 
> second_run.png
>
>
> Moving a user's list discussion over here.
> {color:#00}The very short form is that from Solr 6.6.1 to Solr 8.3.1, the 
> throughput for date boosting in my tests dropped by 40+%{color}
> {color:#00}I’ve been hearing about slowdowns in successive Solr releases 
> with boost functions, so I dug into it a bit. The test setup is just a 
> boost-by-date with an additional big OR clause of 100 random words so I’d be 
> sure to hit a bunch of docs. I figured that if there were few hits, the 
> signal would be lost in the noise, but I didn’t look at the actual hit 
> counts.{color}
> {color:#00}I saw several Solr JIRAs about this subject, but they were 
> slightly different, although quite possibly the same underlying issue. So I 
> tried to get this down to a very specific form of a query.{color}
> {color:#00}I’ve also seen some cases in the wild where the response was 
> proportional to the number of segments, thus my optimize experiments.{color}
> {color:#00}Here are the results, explanation below. O stands for 
> optimized to one segment. I spot checked pdate against 6.6, 7.1 and 8.3 and 
> they weren’t significantly different performance wise from tdate. All have 
> docValues enabled. I ran these against a multiValued=“false” field. All the 
> tests pegged all my CPUs. Jmeter is being run on a different machine than 
> Solr. Only one Solr was running for any test.{color}
> {color:#00}Solr version   queries/min   {color}
> {color:#00}6.6.1  3,400  {color}
> {color:#00}6.6.1 O   4,800  {color}
> {color:#00}7.1 2,800   {color}
> {color:#00}7.1 O 4,200   {color}
> {color:#00}7.7.1  2,400   {color}
> {color:#00}7.7.1 O  3,500    {color}
> {color:#00}8.3.1 2,000    {color}
> {color:#00}8.3.1 O  2,600    {color}
> {color:#00}The tests I’ve been running just index 20M docs into a single 
> core, then run the exact same 10,000 queries against them from jmeter with 24 
> threads. Spot checks showed no hits on the queryResultCache.{color}
> {color:#00}A query looks like this: {color}
> {color:#00}rows=0&\{!boost b=recip(ms(NOW, 
> INSERT_FIELD_HERE),3.16e-11,1,1)}text_txt:(campaigners OR adjourned OR 
> anyplace…97 more random words){color}
> {color:#00}There is no faceting. No grouping. No sorting.{color}
> {color:#00}I fil

[jira] [Updated] (SOLR-14137) Boosting by date (and perhaps others) shows a steady decline 6.6->8.3

[Erick Erickson (Jira)]

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

Erick Erickson updated SOLR-14137:
--
Attachment: second_run.png
Status: Open  (was: Open)

This is a more tightly controlled set of tests. All the indexes are much closer 
to being uniform. By "uniform" I mean:

- The numeric values should be identical across the indexes I generated because 
I used the same random seed

- I bumped the ramBuferSizeMB to 500 and used NoMergePolicy to create the 
index, so any differences between indexes should be minimal.

- The random words chosen for the text may still differ though, I missed that. 
But the results are consistent enough that I'm not going to stress over that 
unless I decide to run them all again.

The results are quite consistent with my earlier run. Note that 6.6.1 and 7.1 
are quite similar, with the biggest jump happening between 7.1 and 7.7.2. 
7.7.2->8.3.1 shows an additional decline.


> Boosting by date (and perhaps others) shows a steady decline 6.6->8.3
> -
>
> Key: SOLR-14137
> URL: https://issues.apache.org/jira/browse/SOLR-14137
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Priority: Major
> Attachments: Screen Shot 2019-12-19 at 2.35.41 PM.png, Screen Shot 
> 2019-12-19 at 3.09.37 PM.png, Screen Shot 2019-12-19 at 3.31.16 PM.png, 
> second_run.png
>
>
> Moving a user's list discussion over here.
> {color:#00}The very short form is that from Solr 6.6.1 to Solr 8.3.1, the 
> throughput for date boosting in my tests dropped by 40+%{color}
> {color:#00}I’ve been hearing about slowdowns in successive Solr releases 
> with boost functions, so I dug into it a bit. The test setup is just a 
> boost-by-date with an additional big OR clause of 100 random words so I’d be 
> sure to hit a bunch of docs. I figured that if there were few hits, the 
> signal would be lost in the noise, but I didn’t look at the actual hit 
> counts.{color}
> {color:#00}I saw several Solr JIRAs about this subject, but they were 
> slightly different, although quite possibly the same underlying issue. So I 
> tried to get this down to a very specific form of a query.{color}
> {color:#00}I’ve also seen some cases in the wild where the response was 
> proportional to the number of segments, thus my optimize experiments.{color}
> {color:#00}Here are the results, explanation below. O stands for 
> optimized to one segment. I spot checked pdate against 6.6, 7.1 and 8.3 and 
> they weren’t significantly different performance wise from tdate. All have 
> docValues enabled. I ran these against a multiValued=“false” field. All the 
> tests pegged all my CPUs. Jmeter is being run on a different machine than 
> Solr. Only one Solr was running for any test.{color}
> {color:#00}Solr version   queries/min   {color}
> {color:#00}6.6.1  3,400  {color}
> {color:#00}6.6.1 O   4,800  {color}
> {color:#00}7.1 2,800   {color}
> {color:#00}7.1 O 4,200   {color}
> {color:#00}7.7.1  2,400   {color}
> {color:#00}7.7.1 O  3,500    {color}
> {color:#00}8.3.1 2,000    {color}
> {color:#00}8.3.1 O  2,600    {color}
> {color:#00}The tests I’ve been running just index 20M docs into a single 
> core, then run the exact same 10,000 queries against them from jmeter with 24 
> threads. Spot checks showed no hits on the queryResultCache.{color}
> {color:#00}A query looks like this: {color}
> {color:#00}rows=0&\{!boost b=recip(ms(NOW, 
> INSERT_FIELD_HERE),3.16e-11,1,1)}text_txt:(campaigners OR adjourned OR 
> anyplace…97 more random words){color}
> {color:#00}There is no faceting. No grouping. No sorting.{color}
> {color:#00}I fill in INSERT_FIELD_HERE through jmeter magic. I’m running 
> the exact same queries for every test.{color}
> {color:#00}One wildcard is that I did regenerate the index for each major 
> revision, and the chose random words from the same list of words, as well as 
> random times (bounded in the same range though) so the docs are not 
> completely identical. The index was in the native format for that major 
> version even if slightly different between versions. I ran the test once, 
> then ran it again after optimizing the index.{color}
> {color:#00}I haven’t dug any farther, if anyone’s interested I can throw 
> a profiler at, say, 8.3 and see what I can see, although I’m not going to 
> have time to dive into this any time soon. I’d be glad to run some tests 
> though. I saved the queries and the indexes so running a test would  only 
> ta

[GitHub] [lucene-solr] janhoy commented on a change in pull request #1109: More pervasive use of PackageLoader / PluginInfo

[GitBox]

janhoy commented on a change in pull request #1109: More pervasive use of 
PackageLoader / PluginInfo
URL: https://github.com/apache/lucene-solr/pull/1109#discussion_r361333891
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/schema/IndexSchemaFactory.java
 ##
 @@ -62,7 +62,7 @@ public static IndexSchema buildIndexSchema(String 
resourceName, SolrConfig confi
 PluginInfo info = config.getPluginInfo(IndexSchemaFactory.class.getName());
 IndexSchemaFactory factory;
 if (null != info) {
-  factory = config.getResourceLoader().newInstance(info.className, 
IndexSchemaFactory.class);
+  factory = config.getResourceLoader().newInstance(info, 
IndexSchemaFactory.class);
 
 Review comment:
   Sound like an exciting design, SRL in response of loading stuff. Could not 
SRL ask SolrCore about version details if it is a core-level package?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Updated] (SOLR-14102) FacetModule use number of responses from shards as number of shards

[Mikhail Khludnev (Jira)]

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

Mikhail Khludnev updated SOLR-14102:

Status: Patch Available  (was: Open)

> FacetModule use number of responses from shards as number of shards
> ---
>
> Key: SOLR-14102
> URL: https://issues.apache.org/jira/browse/SOLR-14102
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomohiro Manabe
>Priority: Major
> Attachments: SOLR-14102.patch
>
>
> Hi, I am developing a SearchComponent which sends some requests to only a 
> part of shards.
> Basically it works well, but using it with facetting triggers an error.
> I found that FacetModule use the number of responses from shards 
> (sreq.responses.size()) as the number of shards.
> Of course this assumption is incorrect in case that only a part of shards 
> respond.
> Instead of the number of responses, using rb.shards.length may be better.



--
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] [Reopened] (SOLR-13817) Deprecate and remove legacy SolrCache implementations

[Andrzej Bialecki (Jira)]

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

Andrzej Bialecki reopened SOLR-13817:
-

They should, I missed it - I'll fix it in a couple days.

> Deprecate and remove legacy SolrCache implementations
> -
>
> Key: SOLR-13817
> URL: https://issues.apache.org/jira/browse/SOLR-13817
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: master (9.0), 8.4
>
> Attachments: SOLR-13817-8x.patch, SOLR-13817-master.patch
>
>
> Now that SOLR-8241 has been committed I propose to deprecate other cache 
> implementations in 8x and remove them altogether from 9.0, in order to reduce 
> confusion and maintenance costs.



--
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] mkhludnev commented on a change in pull request #1122: SOLR-12490 Added parsing of json.queries for referring in JSON facets

[GitBox]

mkhludnev commented on a change in pull request #1122: SOLR-12490 Added parsing 
of json.queries for referring in JSON facets
URL: https://github.com/apache/lucene-solr/pull/1122#discussion_r361335287
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/request/json/RequestUtil.java
 ##
 @@ -191,7 +191,9 @@ public static void processParams(SolrRequestHandler 
handler, SolrQueryRequest re
 }
 
 // implement compat for existing components...
-JsonQueryConverter jsonQueryConverter = new JsonQueryConverter();
+JsonQueryConverter jsonQueryConverter = (JsonQueryConverter) 
req.getContext()
 
 Review comment:
   I think it's necessary only for the earlier "dynamic" approach. I suppose 
it's not necessary in the eager one. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] mkhludnev commented on a change in pull request #1122: SOLR-12490 Added parsing of json.queries for referring in JSON facets

[GitBox]

mkhludnev commented on a change in pull request #1122: SOLR-12490 Added parsing 
of json.queries for referring in JSON facets
URL: https://github.com/apache/lucene-solr/pull/1122#discussion_r361335644
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/request/json/RequestUtil.java
 ##
 @@ -214,37 +216,22 @@ public static void processParams(SolrRequestHandler 
handler, SolrQueryRequest re
   out = "rows";
 } else if (SORT.equals(key)) {
   out = SORT;
+} else if ("queries".equals(key)) {
+  for (Map.Entry subEntry : ((Map) 
entry.getValue()).entrySet()) {
 
 Review comment:
   Pls check before cast, throw exception with meaningful message and assert 
400 http code in test. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] mkhludnev commented on a change in pull request #1122: SOLR-12490 Added parsing of json.queries for referring in JSON facets

[GitBox]

mkhludnev commented on a change in pull request #1122: SOLR-12490 Added parsing 
of json.queries for referring in JSON facets
URL: https://github.com/apache/lucene-solr/pull/1122#discussion_r361335761
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/request/json/RequestUtil.java
 ##
 @@ -214,37 +216,22 @@ public static void processParams(SolrRequestHandler 
handler, SolrQueryRequest re
   out = "rows";
 } else if (SORT.equals(key)) {
   out = SORT;
+} else if ("queries".equals(key)) {
+  for (Map.Entry subEntry : ((Map) 
entry.getValue()).entrySet()) {
+out = subEntry.getKey();
+arr = true;
+isQuery = true;
+processJsonEntry(newMap, jsonQueryConverter, subEntry, out, 
isQuery, arr);
+  }
+  continue;
 } else if ("params".equals(key) || "facet".equals(key) ) {
   // handled elsewhere
   continue;
 } else {
   throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, 
"Unknown top-level key in JSON request : " + key);
 }
 
-Object val = entry.getValue();
-
-if (arr) {
-  String[] existing = newMap.get(out);
-  List lst = val instanceof List ? (List)val : null;
-  int existingSize = existing==null ? 0 : existing.length;
-  int jsonSize = lst==null ? 1 : lst.size();
-  String[] newval = new String[ existingSize + jsonSize ];
-  for (int i=0; i

[jira] [Comment Edited] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets

[Mikhail Khludnev (Jira)]

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

Mikhail Khludnev edited comment on SOLR-12490 at 12/25/19 8:18 PM:
---

[https://github.com/apache/lucene-solr/pull/1122.patch]


was (Author: mkhludnev):
[https://github.com/apache/lucene-solr/pull/1122]

> Query DSL supports for further referring and exclusion in JSON facets 
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
>  Issue Type: Improvement
>  Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
>  Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch, 
> image-2019-10-21-09-37-37-118.png
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> It's spin off from the 
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>  
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like 
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998 
>
> # but we can refer only separate params in {{domain.filter}}, it's not 
> possible to refer separate clauses
> see the first comment



--
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-14131) Add maxQueryLength option to DirectSolrSpellchecker

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14131:


Commit 8f5f18041a9210dec7b9fad28487a05731dc9020 in lucene-solr's branch 
refs/heads/branch_8x from Bruno Roustant
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8f5f180 ]

SOLR-14131: Add maxQueryLength option to DirectSolrSpellchecker.


> Add maxQueryLength option to DirectSolrSpellchecker
> ---
>
> Key: SOLR-14131
> URL: https://issues.apache.org/jira/browse/SOLR-14131
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Andy Webb
>Assignee: Bruno Roustant
>Priority: Minor
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Attempting to spellcheck some long query terms can trigger 
> org.apache.lucene.util.automaton.TooComplexToDeterminizeException. This 
> change (previously discussed in SOLR-13190, and dependent on LUCENE-9102) 
> adds a maxQueryLength option to DirectSolrSpellChecker so that Lucene/Solr 
> can be configured to not attempt to spellcheck terms over a specified length.
> Here's a PR: https://github.com/apache/lucene-solr/pull/1113 



--
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-14131) Add maxQueryLength option to DirectSolrSpellchecker

[Bruno Roustant (Jira)]

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

Bruno Roustant updated SOLR-14131:
--
Fix Version/s: 8.5
   Resolution: Fixed
   Status: Resolved  (was: Patch Available)

Thanks [~andywebb1975]! This will be available in 8.5.

> Add maxQueryLength option to DirectSolrSpellchecker
> ---
>
> Key: SOLR-14131
> URL: https://issues.apache.org/jira/browse/SOLR-14131
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Andy Webb
>Assignee: Bruno Roustant
>Priority: Minor
> Fix For: 8.5
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Attempting to spellcheck some long query terms can trigger 
> org.apache.lucene.util.automaton.TooComplexToDeterminizeException. This 
> change (previously discussed in SOLR-13190, and dependent on LUCENE-9102) 
> adds a maxQueryLength option to DirectSolrSpellChecker so that Lucene/Solr 
> can be configured to not attempt to spellcheck terms over a specified length.
> Here's a PR: https://github.com/apache/lucene-solr/pull/1113 



--
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] noblepaul opened a new pull request #1124: SOLR:14151: Schema components to be loadable from packages

[GitBox]

noblepaul opened a new pull request #1124: SOLR:14151: Schema components to be 
loadable from packages
URL: https://github.com/apache/lucene-solr/pull/1124
 
 
   DO NOT commit WIP


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

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

[Noble Paul (Jira)]

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

Noble Paul updated SOLR-14151:
--
Description: 
Example:

{code:xml}
 

  
  
  
  

  
{code}

* When a package is updated, the entire {{IndexSchema}} object is refreshed, 
but the SolrCore object is not reloaded
* Any component can be prefixed with the package name
* The semantics of loading plugins remain the same as that of the components in 
{{solrconfig.xml}}
* Plugins can be registered using schema API

> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> Example:
> {code:xml}
>  
> 
>   
>generateNumberParts="0" catenateWords="0"
>   catenateNumbers="0" catenateAll="0"/>
>   
>   
> 
>   
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed, 
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components 
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API



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

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1109: More pervasive use of PackageLoader / PluginInfo

[GitBox]

dsmiley commented on a change in pull request #1109: More pervasive use of 
PackageLoader / PluginInfo
URL: https://github.com/apache/lucene-solr/pull/1109#discussion_r361366362
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/core/DirectoryFactory.java
 ##
 @@ -420,7 +420,7 @@ static DirectoryFactory loadDirectoryFactory(SolrConfig 
config, CoreContainer cc
 final DirectoryFactory dirFactory;
 if (info != null) {
   log.debug(info.className);
-  dirFactory = config.getResourceLoader().newInstance(info.className, 
DirectoryFactory.class);
+  dirFactory = config.getResourceLoader().newInstance(info, 
DirectoryFactory.class);
 
 Review comment:
   IndexSchema can be shared ("shareSchema" option) but SolrConfig at present 
cannot be.  Lets suppose it can be for the sake of argument -- wouldn't this be 
a reason to _not_ use SolrCore related things?  Otherwise another Collection 
using the same SolrConfig might theoretically refer to something it shouldn't.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1109: More pervasive use of PackageLoader / PluginInfo

[GitBox]

dsmiley commented on a change in pull request #1109: More pervasive use of 
PackageLoader / PluginInfo
URL: https://github.com/apache/lucene-solr/pull/1109#discussion_r361366578
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/core/SolrCore.java
 ##
 @@ -519,7 +518,7 @@ private IndexDeletionPolicyWrapper 
initDeletionPolicy(IndexDeletionPolicyWrapper
 final PluginInfo info = 
solrConfig.getPluginInfo(IndexDeletionPolicy.class.getName());
 final IndexDeletionPolicy delPolicy;
 if (info != null) {
-  delPolicy = createInstance(info.className, IndexDeletionPolicy.class, 
"Deletion Policy for SOLR", this, getResourceLoader());
+  delPolicy = newInstance(info, IndexDeletionPolicy.class, this, 
getResourceLoader());
 
 Review comment:
   This ultimately calls SRL with PackageInfo which resolves the right package 
classloader there.  That's the central idea of the approach in this PR -- SRL 
owns the resolution.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1109: More pervasive use of PackageLoader / PluginInfo

[GitBox]

dsmiley commented on a change in pull request #1109: More pervasive use of 
PackageLoader / PluginInfo
URL: https://github.com/apache/lucene-solr/pull/1109#discussion_r361367240
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 ##
 @@ -954,4 +987,46 @@ public static void persistConfLocally(SolrResourceLoader 
loader, String resource
 }
   }
 
+  // TODO document these methods...
 
 Review comment:
   The SRL is pervasively used across the codebase to load stuff (hence 
"resource loader" in its name).  If CoreContainer/SolrCore is now the right 
place, then this is a big change; no?
   
   BTW, Wouldn't the ConfigSet object be a more befitting place to store the 
version association than the SolrCore?  Isn't params.json (which is where the 
association is) stored in the config set?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1109: More pervasive use of PackageLoader / PluginInfo

[GitBox]

dsmiley commented on a change in pull request #1109: More pervasive use of 
PackageLoader / PluginInfo
URL: https://github.com/apache/lucene-solr/pull/1109#discussion_r361367530
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/schema/IndexSchemaFactory.java
 ##
 @@ -62,7 +62,7 @@ public static IndexSchema buildIndexSchema(String 
resourceName, SolrConfig confi
 PluginInfo info = config.getPluginInfo(IndexSchemaFactory.class.getName());
 IndexSchemaFactory factory;
 if (null != info) {
-  factory = config.getResourceLoader().newInstance(info.className, 
IndexSchemaFactory.class);
+  factory = config.getResourceLoader().newInstance(info, 
IndexSchemaFactory.class);
 
 Review comment:
   "That's plain wrong. "  Please work on your tone @noblepaul .  There is no 
right/wrong here; we are exploring what the future holds together; it has not 
been written yet with no spec to judge right/wrong.  It would be more correct 
to say "According to my vision, the SRL should not know about packages".


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] kkewwei opened a new pull request #1125: LUCENE-9096: Implementation of CompressingTermVectorsWriter.flushOffsets can be simpler

[GitBox]

kkewwei opened a new pull request #1125: LUCENE-9096: Implementation of 
CompressingTermVectorsWriter.flushOffsets can be simpler
URL: https://github.com/apache/lucene-solr/pull/1125
 
 
   Description
   In CompressingTermVectorsWriter.flushOffsets, the calculation of sumPos and 
sumOffsets is a little redundant
   
   Solution
   Simplify the process.
   
   Tests
   I have no idea how to test it, I‘m really appreciate anyone giving me ideas.
   
   Checklist
   Please review the following and check all that apply:
I have 
   - [ ] reviewed the guidelines for How to Contribute and my code conforms to 
the standards described there to the best of my ability.
   - [ ]  I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers access to contribute to my PR branch. 
(optional but recommended)
   - [ ]  I have developed this patch against the master branch.
   - [ ]  I have run ant precommit and the appropriate test suite.
   - [ ]  I have added tests for my changes.
   - [ ]  I have added documentation for the Ref Guide (for Solr changes only).


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1109: More pervasive use of PackageLoader / PluginInfo

[GitBox]

noblepaul commented on a change in pull request #1109: More pervasive use of 
PackageLoader / PluginInfo
URL: https://github.com/apache/lucene-solr/pull/1109#discussion_r361375529
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/schema/IndexSchemaFactory.java
 ##
 @@ -62,7 +62,7 @@ public static IndexSchema buildIndexSchema(String 
resourceName, SolrConfig confi
 PluginInfo info = config.getPluginInfo(IndexSchemaFactory.class.getName());
 IndexSchemaFactory factory;
 if (null != info) {
-  factory = config.getResourceLoader().newInstance(info.className, 
IndexSchemaFactory.class);
+  factory = config.getResourceLoader().newInstance(info, 
IndexSchemaFactory.class);
 
 Review comment:
   > There is no right/wrong here; 
   
   This is not a personal remark. What I'm saying is "it's plain wrong to load 
using the latest version". 
   
   This is not how the rest of the system work. So, we have to ensure that what 
should be the expectation of the user
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] noblepaul commented on issue #1109: More pervasive use of PackageLoader / PluginInfo

[GitBox]

noblepaul commented on issue #1109: More pervasive use of PackageLoader / 
PluginInfo
URL: https://github.com/apache/lucene-solr/pull/1109#issuecomment-568981311
 
 
   @dsmiley The comments are not supposed to be personal. These are my 
observations on the code/PR. I'm sure somebody is going to remove that "WIP" 
tag pretty soon. There is a ton of work that needs to be done before we can do 
that. So, I'm typing down my observations as I see them. 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left

[GitBox]

dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified 
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361375534
 
 

 ##
 File path: 
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/LengthGoalBreakIterator.java
 ##
 @@ -174,7 +175,48 @@ private int moveToBreak(int idx) { // precondition: idx 
is a known break
   // called at start of new Passage given first word start offset
   @Override
   public int preceding(int offset) {
-return baseIter.preceding(offset); // no change needed
+final int fragmentStart = Math.max(baseIter.preceding(offset), 0); // 
convert DONE to 0
+fragmentEndFromPreceding = baseIter.following(fragmentStart);
 
 Review comment:
   couldn't fragmentStart argument be offset so that baseIter needn't 
re-analyze the text before offset?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left

[GitBox]

dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified 
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361374902
 
 

 ##
 File path: 
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/LengthGoalBreakIterator.java
 ##
 @@ -116,28 +128,20 @@ public int previous() {
 return baseIter.previous();
   }
 
-  // called while the current position is the start of a new passage; find end 
of passage
+  // NOTE: this.fragmentEndFromPreceding is used instead of the parameter!
+  // This is a big diversion from the API a BreakIterator should implement, 
but specifically this optimization is fine.
   @Override
   public int following(int followingIdx) {
 
 Review comment:
   based on your comment, rename this parameter to _unused_followingIdx


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left

[GitBox]

dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified 
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361374225
 
 

 ##
 File path: 
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/LengthGoalBreakIterator.java
 ##
 @@ -33,23 +33,32 @@
 
   private final BreakIterator baseIter;
   private final int lengthGoal;
+  private final float fragmentAlignment; // how much text to align before 
match-fragment, valid in range [0, 1]
   private final boolean isMinimumLength; // if false then is "closest to" 
length
+  private int fragmentEndFromPreceding; // store the match-break end for reuse 
in following()
+  private int fragmentEndFollowingLengthGoalFromPreceding; // store the 
remaining length to collect in following()
 
   /** Breaks will be at least {@code minLength} apart (to the extent 
possible). */
-  public static LengthGoalBreakIterator createMinLength(BreakIterator 
baseIter, int minLength) {
-return new LengthGoalBreakIterator(baseIter, minLength, true);
+  public static LengthGoalBreakIterator createMinLength(BreakIterator 
baseIter, int minLength,
 
 Review comment:
   I propose adding a deprecated version of the current method with 0f for 
back-compat.   Solr won't use it but others out there might.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left

[GitBox]

dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified 
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361374322
 
 

 ##
 File path: 
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/LengthGoalBreakIterator.java
 ##
 @@ -33,23 +33,32 @@
 
   private final BreakIterator baseIter;
   private final int lengthGoal;
+  private final float fragmentAlignment; // how much text to align before 
match-fragment, valid in range [0, 1]
   private final boolean isMinimumLength; // if false then is "closest to" 
length
+  private int fragmentEndFromPreceding; // store the match-break end for reuse 
in following()
+  private int fragmentEndFollowingLengthGoalFromPreceding; // store the 
remaining length to collect in following()
 
   /** Breaks will be at least {@code minLength} apart (to the extent 
possible). */
-  public static LengthGoalBreakIterator createMinLength(BreakIterator 
baseIter, int minLength) {
-return new LengthGoalBreakIterator(baseIter, minLength, true);
+  public static LengthGoalBreakIterator createMinLength(BreakIterator 
baseIter, int minLength,
+float 
fragmentAlignment) {
+return new LengthGoalBreakIterator(baseIter, minLength, 
fragmentAlignment,true);
   }
 
   /** Breaks will be on average {@code targetLength} apart; the closest break 
to this target (before or after)
* is chosen. */
-  public static LengthGoalBreakIterator createClosestToLength(BreakIterator 
baseIter, int targetLength) {
-return new LengthGoalBreakIterator(baseIter, targetLength, false);
+  public static LengthGoalBreakIterator createClosestToLength(BreakIterator 
baseIter, int targetLength,
 
 Review comment:
   Please add a deprecated variant of the old signature.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left

[GitBox]

dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified 
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361376198
 
 

 ##
 File path: 
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/LengthGoalBreakIterator.java
 ##
 @@ -174,7 +175,48 @@ private int moveToBreak(int idx) { // precondition: idx 
is a known break
   // called at start of new Passage given first word start offset
   @Override
   public int preceding(int offset) {
-return baseIter.preceding(offset); // no change needed
+final int fragmentStart = Math.max(baseIter.preceding(offset), 0); // 
convert DONE to 0
+fragmentEndFromPreceding = baseIter.following(fragmentStart);
 
 Review comment:
   A point I want to make is that BreakIterators can be rather expensive and so 
it's good to try to avoid calling it more than needed, and to help it do less 
work.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left

[GitBox]

dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified 
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361370892
 
 

 ##
 File path: 
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/LengthGoalBreakIterator.java
 ##
 @@ -33,23 +33,32 @@
 
   private final BreakIterator baseIter;
   private final int lengthGoal;
+  private final float fragmentAlignment; // how much text to align before 
match-fragment, valid in range [0, 1]
   private final boolean isMinimumLength; // if false then is "closest to" 
length
+  private int fragmentEndFromPreceding; // store the match-break end for reuse 
in following()
+  private int fragmentEndFollowingLengthGoalFromPreceding; // store the 
remaining length to collect in following()
 
   /** Breaks will be at least {@code minLength} apart (to the extent 
possible). */
-  public static LengthGoalBreakIterator createMinLength(BreakIterator 
baseIter, int minLength) {
-return new LengthGoalBreakIterator(baseIter, minLength, true);
+  public static LengthGoalBreakIterator createMinLength(BreakIterator 
baseIter, int minLength,
+float 
fragmentAlignment) {
+return new LengthGoalBreakIterator(baseIter, minLength, 
fragmentAlignment,true);
   }
 
   /** Breaks will be on average {@code targetLength} apart; the closest break 
to this target (before or after)
* is chosen. */
-  public static LengthGoalBreakIterator createClosestToLength(BreakIterator 
baseIter, int targetLength) {
-return new LengthGoalBreakIterator(baseIter, targetLength, false);
+  public static LengthGoalBreakIterator createClosestToLength(BreakIterator 
baseIter, int targetLength,
+  float 
fragmentAlignment) {
+return new LengthGoalBreakIterator(baseIter, targetLength, 
fragmentAlignment, false);
   }
 
-  private LengthGoalBreakIterator(BreakIterator baseIter, int lengthGoal, 
boolean isMinimumLength) {
+  private LengthGoalBreakIterator(BreakIterator baseIter, int lengthGoal, 
float fragmentAlignment,
+  boolean isMinimumLength) {
 this.baseIter = baseIter;
 this.lengthGoal = lengthGoal;
+this.fragmentAlignment = Math.max(Math.min(fragmentAlignment, 1.f), 0.f);
 
 Review comment:
   I would prefer an IllegalArgumentException 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


With regards,
Apache Git Services

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