[jira] [Commented] (SOLR-14064) remove some hadoop brain-damage from build environment

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14064:


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

SOLR-14064: remove some hadoop brain damage from build environment

Some permissions and build hacks were made on behalf of hadoop: hacks on
top of hacks. Now that the major problems such as classpath pollution and
hadoop test code are fixed, so we can remove hacks built on top of them.


> remove some hadoop brain-damage from build environment
> --
>
> Key: SOLR-14064
> URL: https://issues.apache.org/jira/browse/SOLR-14064
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Priority: Major
> Attachments: SOLR-14064.patch
>
>
> Some permissions and build hacks were made on behalf of hadoop. These were 
> most definitely hacks on top of hacks.
> The background is that the hadoop code is a true nightmare to deal with, if 
> you want to sandbox code with SecurityManager.
> Now that [~krisden] has wrestled it (at least mostly?) to the ground, let's 
> remove the hacks from solr security policy and lucene build that I added. We 
> need to be strict: ensure things are really working (otherwise we get 
> SecurityException). This also makes the configuration simpler.



--
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-14064) remove some hadoop brain-damage from build environment

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14064:


Commit 1761e48e534225bec234ea2d0fd223f70c962d5a in lucene-solr's branch 
refs/heads/branch_8x from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1761e48 ]

SOLR-14064: remove some hadoop brain damage from build environment

Some permissions and build hacks were made on behalf of hadoop: hacks on
top of hacks. Now that the major problems such as classpath pollution and
hadoop test code are fixed, so we can remove hacks built on top of them.


> remove some hadoop brain-damage from build environment
> --
>
> Key: SOLR-14064
> URL: https://issues.apache.org/jira/browse/SOLR-14064
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Priority: Major
> Attachments: SOLR-14064.patch
>
>
> Some permissions and build hacks were made on behalf of hadoop. These were 
> most definitely hacks on top of hacks.
> The background is that the hadoop code is a true nightmare to deal with, if 
> you want to sandbox code with SecurityManager.
> Now that [~krisden] has wrestled it (at least mostly?) to the ground, let's 
> remove the hacks from solr security policy and lucene build that I added. We 
> need to be strict: ensure things are really working (otherwise we get 
> SecurityException). This also makes the configuration simpler.



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

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

[jira] [Resolved] (SOLR-14064) remove some hadoop brain-damage from build environment

[Robert Muir (Jira)]

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

Robert Muir resolved SOLR-14064.

Fix Version/s: 8.5
 Assignee: Robert Muir
   Resolution: Fixed

Thanks Kevin!

> remove some hadoop brain-damage from build environment
> --
>
> Key: SOLR-14064
> URL: https://issues.apache.org/jira/browse/SOLR-14064
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-14064.patch
>
>
> Some permissions and build hacks were made on behalf of hadoop. These were 
> most definitely hacks on top of hacks.
> The background is that the hadoop code is a true nightmare to deal with, if 
> you want to sandbox code with SecurityManager.
> Now that [~krisden] has wrestled it (at least mostly?) to the ground, let's 
> remove the hacks from solr security policy and lucene build that I added. We 
> need to be strict: ensure things are really working (otherwise we get 
> SecurityException). This also makes the configuration simpler.



--
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-14076) SearchRateTriggerIntegrationTest: fix static leak

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14076:


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

SOLR-14076: clean up static fields leak in nightly-only test


> SearchRateTriggerIntegrationTest: fix static leak
> -
>
> Key: SOLR-14076
> URL: https://issues.apache.org/jira/browse/SOLR-14076
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Priority: Major
>
> I see this from jenkins:
> {noformat}
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest
> Error Message:
> Clean up static fields (in @AfterClass?) and null them, your test still has 
> references to classes of which the sizes cannot be measured due to security 
> restrictions or Java 9 module encapsulation:   - private static 
> org.apache.solr.client.solrj.cloud.SolrCloudManager 
> org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.cloudManager
> {noformat}



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

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

[jira] [Resolved] (SOLR-14076) SearchRateTriggerIntegrationTest: fix static leak

[Robert Muir (Jira)]

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

Robert Muir resolved SOLR-14076.

Fix Version/s: 8.5
 Assignee: Robert Muir
   Resolution: Fixed

> SearchRateTriggerIntegrationTest: fix static leak
> -
>
> Key: SOLR-14076
> URL: https://issues.apache.org/jira/browse/SOLR-14076
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Major
> Fix For: 8.5
>
>
> I see this from jenkins:
> {noformat}
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest
> Error Message:
> Clean up static fields (in @AfterClass?) and null them, your test still has 
> references to classes of which the sizes cannot be measured due to security 
> restrictions or Java 9 module encapsulation:   - private static 
> org.apache.solr.client.solrj.cloud.SolrCloudManager 
> org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.cloudManager
> {noformat}



--
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-14076) SearchRateTriggerIntegrationTest: fix static leak

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14076:


Commit 4a3fa721fb37ed10a46871d027eb90d3cc5c7a0a in lucene-solr's branch 
refs/heads/branch_8x from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4a3fa72 ]

SOLR-14076: clean up static fields leak in nightly-only test


> SearchRateTriggerIntegrationTest: fix static leak
> -
>
> Key: SOLR-14076
> URL: https://issues.apache.org/jira/browse/SOLR-14076
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Priority: Major
>
> I see this from jenkins:
> {noformat}
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest
> Error Message:
> Clean up static fields (in @AfterClass?) and null them, your test still has 
> references to classes of which the sizes cannot be measured due to security 
> restrictions or Java 9 module encapsulation:   - private static 
> org.apache.solr.client.solrj.cloud.SolrCloudManager 
> org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.cloudManager
> {noformat}



--
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-9091) UnifiedHighlighter HTML escaping should only escape essentials

[Lucene/Solr QA (Jira)]

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

Lucene/Solr QA commented on LUCENE-9091:


| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 5 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  3m 
15s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m 
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 40s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
12s{color} | {color:green} highlighter in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 89m 
14s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}102m 14s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-9091 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12988720/LUCENE-9091.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 3ba0054 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/244/testReport/ |
| modules | C: lucene lucene/highlighter solr/core U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/244/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> UnifiedHighlighter HTML escaping should only escape essentials
> --
>
> Key: LUCENE-9091
> URL: https://issues.apache.org/jira/browse/LUCENE-9091
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Nándor Mátravölgyi
>Priority: Minor
> Attachments: LUCENE-9091.patch
>
>
> The unified highlighter does not use the 
> *org.apache.lucene.search.highlight.SimpleHTMLEncoder* through 
> *org.apache.solr.highlight.HtmlEncoder*. It has the HTML escaping feature 
> re-implemented and embedded in the 
> *org.apache.lucene.search.uhighlight.DefaultPassageFormatter*.
> The HTML escaping done by the unified highlighter escapes characters that do 
> not need it. This makes the result payload 50%+ more heavy with no benefit.
> Here is a highlight snippet using the original highlighter:
> {noformat}
> A filter that stems words using a Snowball-generated stemmer. 
> Available stemmers & x are listed in org.tartarus.snowball.ext. Note: 
> This filter is aware of the KeywordAttribute.
> {noformat}
> Here is the same highlight snippet using the unified highlighter:
> {noformat}
> A filter that stems words using a Snowball-generated stemmer. Available stemmers & x are listed in org.tartarus.snowball.ext. Note: This filter is aware of the KeywordAttribute.
> {noformat}
> Maybe I'm missing the point why this is done the way it is. If this behaviour 
> is desired for some use-case it should be a separate encoder, and the HTML 
> encoder should only escape the necessary characters.
> Affects all versions of Lucene-Solr since the addition of the 
> UnifiedHighlighter. Here are the lines where the escaping are implemented 
> differently:
>  * [Escaping by the unified 
> highlighter|https://github.com/apache/lucene-solr/blob/2387bb9d60ae44eeeb4fbcb2f2877f46be5303a0/lucene/highlighter/src/ja

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

[Robert Muir (Jira)]

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

Robert Muir commented on SOLR-13778:


{quote}
Adding javax.net.ssl.SSLException to retriable exceptions makes the test pass. 
But I don't know if it's a good fix; I don't know who came up with "retriable" 
classes or why they're there in the first place. Neither can I explain the 
difference between the two (seems like a different underlying close operation 
on sockets).
{quote}

The list comes from http client. Some retry is listed in http/1.1 specs, 
because it reuses one underlying connection for multiple requests and so on 
(e.g. keep-alive can time out). But here SocketException gets boxed in an 
SSLException so it doesn't happen?


> 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: dumps-LegacyCloud.zip, logs-2019-12-12-1.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

[jira] [Created] (LUCENE-9092) Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2

[Dawid Weiss (Jira)]

Dawid Weiss created LUCENE-9092:
---

 Summary: Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2
 Key: LUCENE-9092
 URL: https://issues.apache.org/jira/browse/LUCENE-9092
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Dawid Weiss
Assignee: Dawid Weiss
 Fix For: master (9.0)






--
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-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=16995548#comment-16995548
 ] 

Dawid Weiss commented on SOLR-13778:


[~hossman] What do you think - should we just add SSLException to the retry 
list?

> 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: dumps-LegacyCloud.zip, logs-2019-12-12-1.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

[jira] [Comment Edited] (SOLR-13804) ant precommit fails on OpenJDK11 Corretto

[Vincenzo D'Amore (Jira)]

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

Vincenzo D'Amore edited comment on SOLR-13804 at 12/13/19 11:14 AM:


This is not a problem anymore. The build now is successfully completed.

I tried the build with Corretto 11.0.5.10.2 

openjdk version "11.0.5" 2019-10-15 LTS
 OpenJDK Runtime Environment Corretto-11.0.5.10.2 (build 11.0.5+10-LTS)
 OpenJDK 64-Bit Server VM Corretto-11.0.5.10.2 (build 11.0.5+10-LTS, mixed mode)

I think we can close this ticket. 

 


was (Author: v.dam...@gmail.com):
This is not a problem anymore.

I tried the build with Corretto 11.0.5.10.2 

openjdk version "11.0.5" 2019-10-15 LTS
OpenJDK Runtime Environment Corretto-11.0.5.10.2 (build 11.0.5+10-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.5.10.2 (build 11.0.5+10-LTS, mixed mode)

I think we can close this ticket. 

 

> ant precommit fails on OpenJDK11 Corretto
> -
>
> Key: SOLR-13804
> URL: https://issues.apache.org/jira/browse/SOLR-13804
> Project: Solr
>  Issue Type: Bug
>Reporter: Koen De Groote
>Priority: Minor
> Attachments: ant_precommit_fails.txt, 
> solr-ant-precommit-with-Corretto-11.0.5.10.2.txt.gz
>
>
> Noticed this while preparing for another pull request. I've attached a file 
> with the output of the command. Errors start at point 4.
>  
> I'm not sure if this is down to it being Corretto, or just anything other 
> than Oracle JDK.
> At the time of writing latest commit was 
> 67f4c7f36eef2ae75fb80859dfc0e612675cb94d
> My knowledge does not extend far enough to say anything meaningful about this.
> So I'm asking here for people to take a look at it.
>  
> Corretto is Amazon's OpenJDK implementation: 
> https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/what-is-corretto-11.html
>  



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

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

[jira] [Comment Edited] (SOLR-13804) ant precommit fails on OpenJDK11 Corretto

[Vincenzo D'Amore (Jira)]

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

Vincenzo D'Amore edited comment on SOLR-13804 at 12/13/19 11:16 AM:


This is not a problem anymore. The build now is successfully completed.

{{precommit:}}

{{BUILD SUCCESSFUL}}
{{Total time: 28 minutes 42 seconds}}

I tried the build with Corretto 11.0.5.10.2 

openjdk version "11.0.5" 2019-10-15 LTS
 OpenJDK Runtime Environment Corretto-11.0.5.10.2 (build 11.0.5+10-LTS)
 OpenJDK 64-Bit Server VM Corretto-11.0.5.10.2 (build 11.0.5+10-LTS, mixed mode)

I think we can close this ticket. 

 


was (Author: v.dam...@gmail.com):
This is not a problem anymore. The build now is successfully completed.

I tried the build with Corretto 11.0.5.10.2 

openjdk version "11.0.5" 2019-10-15 LTS
 OpenJDK Runtime Environment Corretto-11.0.5.10.2 (build 11.0.5+10-LTS)
 OpenJDK 64-Bit Server VM Corretto-11.0.5.10.2 (build 11.0.5+10-LTS, mixed mode)

I think we can close this ticket. 

 

> ant precommit fails on OpenJDK11 Corretto
> -
>
> Key: SOLR-13804
> URL: https://issues.apache.org/jira/browse/SOLR-13804
> Project: Solr
>  Issue Type: Bug
>Reporter: Koen De Groote
>Priority: Minor
> Attachments: ant_precommit_fails.txt, 
> solr-ant-precommit-with-Corretto-11.0.5.10.2.txt.gz
>
>
> Noticed this while preparing for another pull request. I've attached a file 
> with the output of the command. Errors start at point 4.
>  
> I'm not sure if this is down to it being Corretto, or just anything other 
> than Oracle JDK.
> At the time of writing latest commit was 
> 67f4c7f36eef2ae75fb80859dfc0e612675cb94d
> My knowledge does not extend far enough to say anything meaningful about this.
> So I'm asking here for people to take a look at it.
>  
> Corretto is Amazon's OpenJDK implementation: 
> https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/what-is-corretto-11.html
>  



--
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-13360) StringIndexOutOfBoundsException: String index out of range: -3

[Vincenzo D'Amore (Jira)]

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

Vincenzo D'Amore commented on SOLR-13360:
-

Without a reproducible example of the problem I was unable to trigger the 
problem. could you please attache a minimal reproducible example of the issue?

> StringIndexOutOfBoundsException: String index out of range: -3
> --
>
> Key: SOLR-13360
> URL: https://issues.apache.org/jira/browse/SOLR-13360
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 7.2.1
> Environment: Solr 7.2.1 - SAP Hybris 6.7.0.8
>Reporter: Ahmed Ghoneim
>Priority: Critical
>
> *{color:#ff}I cannot execute the following query:{color}*
> {noformat}
> http://localhost:8983/solr/master_Project_Product_flip/suggest?q=duotop&spellcheck.q=duotop&qt=/suggest&spellcheck.dictionary=de&spellcheck.collate=true{noformat}
> 4/1/2019, 1:16:07 PM ERROR true RequestHandlerBase 
> java.lang.StringIndexOutOfBoundsException: String index out of range: -3
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -3
>   at 
> java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:851)
>   at java.lang.StringBuilder.replace(StringBuilder.java:262)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:252)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:94)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:297)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:209)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:710)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:534)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
>   at 
> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:251)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
>   at 
> o

[GitHub] [lucene-solr] sigram commented on a change in pull request #1071: SOLR-14003: Refactor code to avoid reading state from Replica/Slic

[GitBox]

sigram commented on a change in pull request #1071: SOLR-14003: Refactor code 
to avoid reading state from Replica/Slic
URL: https://github.com/apache/lucene-solr/pull/1071#discussion_r357611735
 
 

 ##
 File path: 
solr/solrj/src/java/org/apache/solr/client/solrj/cloud/ShardStateProvider.java
 ##
 @@ -0,0 +1,56 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.client.solrj.cloud;
+
+import org.apache.solr.common.cloud.Replica;
+import org.apache.solr.common.cloud.Slice;
+/**An implementation that fetches the state of each replica/slice and leaders 
of shards in a collection.
+ * The state is embedded with other topology information in state.json in the 
original SolrCLoud design.
+ * But, it is possible to have another implementation where the state and 
leader information can be stored and read
+ * from other places.
+ *
+ */
+public interface ShardStateProvider {
+
+  /**Get the state of  a given {@link Replica}
+   */
+  Replica.State getState(Replica replica);
+
+  /**Get the leader {@link Replica} of the shard
+   */
+  Replica getLeader(Slice slice);
 
 Review comment:
   See the comment above - we're not getting this information from the `Slice` 
object, do we? Then it should be a default method that simply extracts 
collection and shard name.


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] sigram commented on a change in pull request #1071: SOLR-14003: Refactor code to avoid reading state from Replica/Slic

[GitBox]

sigram commented on a change in pull request #1071: SOLR-14003: Refactor code 
to avoid reading state from Replica/Slic
URL: https://github.com/apache/lucene-solr/pull/1071#discussion_r357610079
 
 

 ##
 File path: 
solr/solrj/src/java/org/apache/solr/client/solrj/cloud/DirectShardState.java
 ##
 @@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.client.solrj.cloud;
+
+import java.util.function.Predicate;
+
+import org.apache.solr.common.cloud.Replica;
+import org.apache.solr.common.cloud.Slice;
+
+/**Reads the state from state.json
+ *
+ */
+public class DirectShardState implements ShardStateProvider {
 
 Review comment:
   IMHO having this class is harmful to the intended goal, because it maintains 
the illusion that replica state is actually kept up to date inside the 
`Replica` object. The whole point of this refactoring, as I understand it, is 
that the state is maintained elsewhere.
   I would even go as far as to completely remove `Replica.getState()`.


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] sigram commented on a change in pull request #1071: SOLR-14003: Refactor code to avoid reading state from Replica/Slic

[GitBox]

sigram commented on a change in pull request #1071: SOLR-14003: Refactor code 
to avoid reading state from Replica/Slic
URL: https://github.com/apache/lucene-solr/pull/1071#discussion_r357612475
 
 

 ##
 File path: 
solr/solrj/src/java/org/apache/solr/client/solrj/cloud/ShardStateProvider.java
 ##
 @@ -0,0 +1,56 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.client.solrj.cloud;
+
+import org.apache.solr.common.cloud.Replica;
+import org.apache.solr.common.cloud.Slice;
+/**An implementation that fetches the state of each replica/slice and leaders 
of shards in a collection.
+ * The state is embedded with other topology information in state.json in the 
original SolrCLoud design.
+ * But, it is possible to have another implementation where the state and 
leader information can be stored and read
+ * from other places.
+ *
+ */
+public interface ShardStateProvider {
+
+  /**Get the state of  a given {@link Replica}
+   */
+  Replica.State getState(Replica replica);
+
+  /**Get the leader {@link Replica} of the shard
+   */
+  Replica getLeader(Slice slice);
+
+  /**Get the leader of the slice. Wait for one if there is no leader
+   * @param timeout how much time to wait for a leader to com eup. -1 means 
the default value will be used
+   * Throws an {@link InterruptedException} if interrupted in between
+   */
+  Replica getLeader(Slice slice, int timeout) throws InterruptedException;
+
+
+  Replica getLeader(String collection, String slice, int timeout) throws 
InterruptedException;
+
+
+  /**CHeck if the replica is active
+   *
+   */
+  boolean isActive(Replica replica);
 
 Review comment:
   See comments above about using default methods that extract identifiers from 
the object.


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] sigram commented on a change in pull request #1071: SOLR-14003: Refactor code to avoid reading state from Replica/Slic

[GitBox]

sigram commented on a change in pull request #1071: SOLR-14003: Refactor code 
to avoid reading state from Replica/Slic
URL: https://github.com/apache/lucene-solr/pull/1071#discussion_r357612198
 
 

 ##
 File path: 
solr/solrj/src/java/org/apache/solr/client/solrj/cloud/ShardStateProvider.java
 ##
 @@ -0,0 +1,56 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.client.solrj.cloud;
+
+import org.apache.solr.common.cloud.Replica;
+import org.apache.solr.common.cloud.Slice;
+/**An implementation that fetches the state of each replica/slice and leaders 
of shards in a collection.
+ * The state is embedded with other topology information in state.json in the 
original SolrCLoud design.
+ * But, it is possible to have another implementation where the state and 
leader information can be stored and read
+ * from other places.
+ *
+ */
+public interface ShardStateProvider {
+
+  /**Get the state of  a given {@link Replica}
+   */
+  Replica.State getState(Replica replica);
+
+  /**Get the leader {@link Replica} of the shard
+   */
+  Replica getLeader(Slice slice);
+
+  /**Get the leader of the slice. Wait for one if there is no leader
+   * @param timeout how much time to wait for a leader to com eup. -1 means 
the default value will be used
+   * Throws an {@link InterruptedException} if interrupted in between
+   */
+  Replica getLeader(Slice slice, int timeout) throws InterruptedException;
 
 Review comment:
   These two methods should also throw a TimeoutException or something like 
that when `timeout > 0`, because this value indicates the user's intent to get 
a definitive answer.


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] sigram commented on a change in pull request #1071: SOLR-14003: Refactor code to avoid reading state from Replica/Slic

[GitBox]

sigram commented on a change in pull request #1071: SOLR-14003: Refactor code 
to avoid reading state from Replica/Slic
URL: https://github.com/apache/lucene-solr/pull/1071#discussion_r357611499
 
 

 ##
 File path: 
solr/solrj/src/java/org/apache/solr/client/solrj/cloud/ShardStateProvider.java
 ##
 @@ -0,0 +1,56 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.client.solrj.cloud;
+
+import org.apache.solr.common.cloud.Replica;
+import org.apache.solr.common.cloud.Slice;
+/**An implementation that fetches the state of each replica/slice and leaders 
of shards in a collection.
+ * The state is embedded with other topology information in state.json in the 
original SolrCLoud design.
+ * But, it is possible to have another implementation where the state and 
leader information can be stored and read
+ * from other places.
+ *
+ */
+public interface ShardStateProvider {
+
+  /**Get the state of  a given {@link Replica}
+   */
+  Replica.State getState(Replica replica);
 
 Review comment:
   As I understand it, the true state is no longer maintained in `Replica` so 
this should be just a default method that delegates to the methods that use 
only replica identifier(s) (such as collection, shard, coreNode or coreName) 
and don't need the actual object.


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] sigram commented on a change in pull request #1071: SOLR-14003: Refactor code to avoid reading state from Replica/Slic

[GitBox]

sigram commented on a change in pull request #1071: SOLR-14003: Refactor code 
to avoid reading state from Replica/Slic
URL: https://github.com/apache/lucene-solr/pull/1071#discussion_r357612840
 
 

 ##
 File path: solr/solrj/src/java/org/apache/solr/common/cloud/Replica.java
 ##
 @@ -167,11 +167,15 @@ public String getNodeName() {
 return nodeName;
   }
   
-  /** Returns the {@link State} of this replica. */
+  /** Returns the {@link State} of this replica. use {@link 
org.apache.solr.client.solrj.cloud.ShardStateProvider#getState(Replica)}  
instead*/
+  @Deprecated
   public State getState() {
 
 Review comment:
   To be removed in 9.0?


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-14048) Improve Hadoop test sanity checks

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14048:


Commit 3ba005465a5dff3975b85f9c44d365bd3cd36346 in lucene-solr's branch 
refs/heads/gradle-master from Kevin Risden
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3ba0054 ]

SOLR-14048: Improve Hadoop test sanity checks

Signed-off-by: Kevin Risden 


> Improve Hadoop test sanity checks
> -
>
> Key: SOLR-14048
> URL: https://issues.apache.org/jira/browse/SOLR-14048
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Fix For: 8.5
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Add more checks around the Hadoop modified classes we use.
> Some ideas from [~hossman] in SOLR-14033
> * some dev docs (package level javadocs?) explaining the whole 
> {{org.apache.hadoop}} "shadow" class impls
> * ideally include some hook in {{HdfsTestUtil}} that causes it to fail fast 
> if it can detect that the classloader didn't pick up our modified classes? .. 
> maybe by adding a new {{public static final Object 
> SOLR_HACK_FOR_CLASS_VERIFICATION = new Object}} to each 
> {{org.apache.hadoop.\*\*}} that it could check for via reflection?



--
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-9092) Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2

[ASF subversion and git services (Jira)]

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

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

Commit 517261dcff8d93a949f6b162b5232c7700ad2d29 in lucene-solr's branch 
refs/heads/gradle-master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=517261d ]

LUCENE-9092: Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2


> Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2
> 
>
> Key: LUCENE-9092
> URL: https://issues.apache.org/jira/browse/LUCENE-9092
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>




--
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-14064) remove some hadoop brain-damage from build environment

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14064:


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

SOLR-14064: remove some hadoop brain damage from build environment

Some permissions and build hacks were made on behalf of hadoop: hacks on
top of hacks. Now that the major problems such as classpath pollution and
hadoop test code are fixed, so we can remove hacks built on top of them.


> remove some hadoop brain-damage from build environment
> --
>
> Key: SOLR-14064
> URL: https://issues.apache.org/jira/browse/SOLR-14064
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-14064.patch
>
>
> Some permissions and build hacks were made on behalf of hadoop. These were 
> most definitely hacks on top of hacks.
> The background is that the hadoop code is a true nightmare to deal with, if 
> you want to sandbox code with SecurityManager.
> Now that [~krisden] has wrestled it (at least mostly?) to the ground, let's 
> remove the hacks from solr security policy and lucene build that I added. We 
> need to be strict: ensure things are really working (otherwise we get 
> SecurityException). This also makes the configuration simpler.



--
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-9092) Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2

[ASF subversion and git services (Jira)]

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

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

Commit 528a2ecb56f75dbda45082f0cff132cd719a7628 in lucene-solr's branch 
refs/heads/gradle-master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=528a2ec ]

LUCENE-9092: Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2 
(follow-up)


> Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2
> 
>
> Key: LUCENE-9092
> URL: https://issues.apache.org/jira/browse/LUCENE-9092
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>




--
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-14076) SearchRateTriggerIntegrationTest: fix static leak

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14076:


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

SOLR-14076: clean up static fields leak in nightly-only test


> SearchRateTriggerIntegrationTest: fix static leak
> -
>
> Key: SOLR-14076
> URL: https://issues.apache.org/jira/browse/SOLR-14076
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Major
> Fix For: 8.5
>
>
> I see this from jenkins:
> {noformat}
> 1 tests failed.
> FAILED:  
> junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest
> Error Message:
> Clean up static fields (in @AfterClass?) and null them, your test still has 
> references to classes of which the sizes cannot be measured due to security 
> restrictions or Java 9 module encapsulation:   - private static 
> org.apache.solr.client.solrj.cloud.SolrCloudManager 
> org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.cloudManager
> {noformat}



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

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

[jira] [Resolved] (SOLR-13804) ant precommit fails on OpenJDK11 Corretto

[Mikhail Khludnev (Jira)]

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

Mikhail Khludnev resolved SOLR-13804.
-
Resolution: Not A Problem

Thanks, [~v.dam...@gmail.com] for checking.

> ant precommit fails on OpenJDK11 Corretto
> -
>
> Key: SOLR-13804
> URL: https://issues.apache.org/jira/browse/SOLR-13804
> Project: Solr
>  Issue Type: Bug
>Reporter: Koen De Groote
>Priority: Minor
> Attachments: ant_precommit_fails.txt, 
> solr-ant-precommit-with-Corretto-11.0.5.10.2.txt.gz
>
>
> Noticed this while preparing for another pull request. I've attached a file 
> with the output of the command. Errors start at point 4.
>  
> I'm not sure if this is down to it being Corretto, or just anything other 
> than Oracle JDK.
> At the time of writing latest commit was 
> 67f4c7f36eef2ae75fb80859dfc0e612675cb94d
> My knowledge does not extend far enough to say anything meaningful about this.
> So I'm asking here for people to take a look at it.
>  
> Corretto is Amazon's OpenJDK implementation: 
> https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/what-is-corretto-11.html
>  



--
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-14079) SPLITSHARD splitByPrefix doesn't work in async mode

[Yonik Seeley (Jira)]

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

Yonik Seeley commented on SOLR-14079:
-

bq. The patch is using different but constant async id's for the different 
stages.

That's just the test using the constant async ids for the different split calls.

bq. is there a fundamental reason this can't work async

We could use an async call and then wait for it (effectively turning it into a 
synchronous call), but at that point in the code, it is synchronous behavior we 
want (we can't proceed until we know the ranges for the new sub-shards.)

I'm new to the Overseer (I've successfully avoided it before ;-), so my 
assumption on async calls is that I just didn't know how to use the API 
properly, and that the response looks different when using async.  Because of 
this, the returned "ranges" wasn't found.  If there are bugs/problems with 
async calls, or other bugs in SplitShardCmd, then those can be handled in 
additional JIRA issues.



> SPLITSHARD splitByPrefix doesn't work in async mode
> ---
>
> Key: SOLR-14079
> URL: https://issues.apache.org/jira/browse/SOLR-14079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-14079.patch
>
>
> If you specify async=whatever in conjunction with splitByPrefix, the ranges 
> are calculated by the shard leader, but that information does not make it 
> back to the overseer and the split proceeds to just split down the middle.



--
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-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison commented on SOLR-14054:


Interesting.  Thank you!  I'm reliably getting the PDType1Font class loading 
issue back to 8.0.0.  How has this not been reported?!  Will try different 
versions of Java.

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
>
> We just released 1.23.  Let's upgrade Tika.



--
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] asfgit closed pull request #1070: LUCENE-9089: FST Builder fluent-style constructor.

[GitBox]

asfgit closed pull request #1070: LUCENE-9089: FST Builder fluent-style 
constructor.
URL: https://github.com/apache/lucene-solr/pull/1070
 
 
   


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-9089) FST.Builder with fluent-style constructor

[ASF subversion and git services (Jira)]

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

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

Commit 1812b367abad0fe9f123fd8f9ffb11c7dc155404 in lucene-solr's branch 
refs/heads/master from Bruno Roustant
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1812b36 ]

LUCENE-9089: FST Builder renamed FSTCompiler with fluent-style Builder.

Closes #1070


> FST.Builder with fluent-style constructor
> -
>
> Key: LUCENE-9089
> URL: https://issues.apache.org/jira/browse/LUCENE-9089
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Bruno Roustant
>Assignee: Bruno Roustant
>Priority: Minor
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> A first step in a try to make the FST code easier to read and evolve. This 
> step is just about the FST Builder constructor.
> By making it fluent, the many calls to it are simplified and it becomes easy 
> to spot the intent and special param tuning.
> No functional change.



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

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

[jira] [Comment Edited] (SOLR-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison edited comment on SOLR-14054 at 12/13/19 1:57 PM:
--

Interesting.  Thank you!  I'm reliably getting the PDType1Font and 
FontMapperImpl$DefaultFontProvider class loading issue back to 8.0.0.  How has 
this not been reported?! 


was (Author: talli...@mitre.org):
Interesting.  Thank you!  I'm reliably getting the PDType1Font class loading 
issue back to 8.0.0.  How has this not been reported?!  Will try different 
versions of Java.

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
>
> We just released 1.23.  Let's upgrade Tika.



--
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-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison commented on SOLR-14054:


https://github.com/curationexperts/epigaea/issues/748 :P

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
>
> We just released 1.23.  Let's upgrade Tika.



--
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-9092) Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2

[Dawid Weiss (Jira)]

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

Dawid Weiss resolved LUCENE-9092.
-
Resolution: Fixed

> Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2
> 
>
> Key: LUCENE-9092
> URL: https://issues.apache.org/jira/browse/LUCENE-9092
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>




--
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-13839) MaxScore is returned as NAN when group.query doesn't match any docs

[Guna Sekhar Dora (Jira)]

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

Guna Sekhar Dora commented on SOLR-13839:
-

[~munendrasn] I'll work on this bug.

> MaxScore is returned as NAN when group.query doesn't match any docs
> ---
>
> Key: SOLR-13839
> URL: https://issues.apache.org/jira/browse/SOLR-13839
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Munendra S N
>Priority: Minor
> Attachments: SOLR-13839.patch
>
>
> When the main query matches some products but group.query doesn't match any 
> docs then maxScore=NAN would be returned in the response.
> * This happens only in standalone/single shard mode
> * score needs to fetched in the response to encounter this issue



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

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

[jira] [Updated] (LUCENE-9077) Gradle build

[Dawid Weiss (Jira)]

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

Dawid Weiss updated LUCENE-9077:

Description: 
tThis task focuses on providing gradle-based build equivalent for Lucene and 
Solr (on master branch). See notes below on why this respin is needed.

The code lives on *gradle-master* branch. It is kept with sync with *master*. 
Try running the following to see an overview of helper guides concerning 
typical workflow, testing and ant-migration helpers:

gradlew :help

A list of items that needs to be added or requires work. If you'd like to work 
on any of these, please add your name to the list. Once you have a patch/ pull 
request let me (dweiss) know - I'll try to coordinate the merges.
 * (/) Apply forbiddenAPIs
 * (/) Generate hardware-aware gradle defaults for parallelism (count of 
workers and test JVMs).
 * (/) Fail the build if --tests filter is applied and no tests execute during 
the entire build (this allows for an empty set of filtered tests at single 
project level).
 * (/) Port other settings and randomizations from common-build.xml
 * (/) Configure security policy/ sandboxing for tests.
 * (/) test's console output on -Ptests.verbose=true
 * (/) add a :helpDeps explanation to how the dependency system works (palantir 
plugin, lockfile) and how to retrieve structured information about current 
dependencies of a given module (in a tree-like output).
 * (/) jar checksums, jar checksum computation and validation. This should be 
done without intermediate folders (directly on dependency sets).
 * identify and list precommit tasks so that they can be ported one by one. 
(Mark's branch has some of this stuff already implemented)
 * Repro-line for failed tests/ runs.

Hard-to-implement stuff already investigated:
 * (!) *Printing console output of failed tests.* There doesn't seem to be any 
way to do this in a reasonably efficient way. There are onOutput listeners but 
they're slow to operate and solr tests emit *tons* of output so it's an 
overkill. The only solution I think would be feasible is to parse test report 
XMLs after the tests are complete and collect the output of failed tests from 
there. The downside is that XMLs contain separated sysout/syserr.
 * (!) *Tests working with security-debug logs or other JVM-early log output*. 
From what I can see in the code Gradle's test runner works by redirecting 
Java's stdout/ syserr so this just won't work. Perhaps we can spin the 
ant-based test runner for such corner-cases.

Of lesser importance:
 * add rendering of javadocs (gradlew javadoc) and attaching them to maven 
publications.
 * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid 
it'll be difficult to run it sensibly because gradle doesn't offer cwd 
separation for the forked test runners.
 * if you diff solr packaged distribution against ant-created distribution 
there are minor differences in library versions and some JARs are excluded/ 
moved around. I didn't try to force these as everything seems to work (tests, 
etc.) – perhaps these differences should  be fixed in the ant build instead.
 * identify and port any other "check" utilities that may be called from ant. 
(Mark's branch has some of this stuff already implemented)
 * [EOE] identify and port various "regenerate" tasks from ant builds (javacc, 
precompiled automata, etc.)
 * fill in POM details in gradle/defaults-maven.gradle so that they reflect the 
previous content better (dependencies aside).
 * Add any IDE integration layers that should be added (I use IntelliJ and it 
imports the project out of the box, without the need for any special tuning).
 * *Clean up dependencies, especially for Solr*: any \{ transitive = false } 
should just explicitly exclude whatever they don't need (and their dependencies 
currently declared explicitly should be folded). Figure out which scope to 
import a dependency to.
 * Add Solr packaging for docs/* (see TODO in packaging/build.gradle; currently 
XSLT...)
 * I didn't bother adding Solr dist/test-framework to packaging (who'd use it 
from a binary distribution? 

 

*{color:#ff}Note:{color}* this builds on the work done by Mark Miller and 
Cao Mạnh Đạt but also applies lessons learned from those two efforts:
 * *Do not try to do too many things at once*. If we deviate too far from 
master, the branch will be hard to merge.
 * *Do everything in baby-steps* and add small, independent build fragments 
replacing the old ant infrastructure.
 * *Try to engage people to run, test and contribute early*. It can't be a 
one-man effort. The more people understand and can contribute to the build, the 
more healthy it will be.

 

  was:
tThis task focuses on providing gradle-based build equivalent for Lucene and 
Solr (on master branch). See notes below on why this respin is needed.

The code lives on *gradle-master* branch. It is kept with sync with *master*. 

[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=16995664#comment-16995664
 ] 

Dawid Weiss commented on SOLR-13778:


{quote}bq. But here SocketException gets boxed in an SSLException so it doesn't 
happen?

 
{quote}

> 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: dumps-LegacyCloud.zip, logs-2019-12-12-1.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

[jira] [Comment Edited] (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=16995664#comment-16995664
 ] 

Dawid Weiss edited comment on SOLR-13778 at 12/13/19 2:27 PM:
--

{quote}
But here SocketException gets boxed in an SSLException so it doesn't happen?
{quote}

Correct. And we don't retry on SSLException (it's in the explicit list of 
non-retriable exceptions).


was (Author: dweiss):
{quote}bq. But here SocketException gets boxed in an SSLException so it doesn't 
happen?

 
{quote}

> 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: dumps-LegacyCloud.zip, logs-2019-12-12-1.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

[jira] [Commented] (LUCENE-9092) Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2

[ASF subversion and git services (Jira)]

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

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

Commit d130bffa8f969d027f985f47124bf9d72f5bb7e2 in lucene-solr's branch 
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d130bff ]

LUCENE-9092: Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2


> Upgrade randomizedtesting to 2.7.5 and Carrot2 to 3.16.2
> 
>
> Key: LUCENE-9092
> URL: https://issues.apache.org/jira/browse/LUCENE-9092
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>




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

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

[jira] [Comment Edited] (SOLR-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison edited comment on SOLR-14054 at 12/13/19 2:36 PM:
--

I'm seeing similar behavior in Solr at least back to 8.3.1 and with other 
classes, e.g.:

{noformat}
java.lang.NoClassDefFoundError: Could not initialize class 
org.apache.pdfbox.pdmodel.font.PDType1Font
at 
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62) 
~[?:?]
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:146) 
~[?:?]
at 
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
 ~[?:?]
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:848)
 ~[?:?]
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:503)
 ~[?:?]
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:477)
 ~[?:?]
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:150)
 ~[?:?]
at 
org.apache.pdfbox.text.LegacyPDFStreamEngine.processPage(LegacyPDFStreamEngine.java:139)
 ~[?:?]
at 
org.apache.pdfbox.text.PDFTextStripper.processPage(PDFTextStripper.java:391) 
~[?:?]
at org.apache.tika.parser.pdf.PDF2XHTML.processPage(PDF2XHTML.java:147) 
~[?:?]
at 
org.apache.pdfbox.text.PDFTextStripper.processPages(PDFTextStripper.java:319) 
~[?:?]
at 
org.apache.pdfbox.text.PDFTextStripper.writeText(PDFTextStripper.java:266) 
~[?:?]
at org.apache.tika.parser.pdf.PDF2XHTML.process(PDF2XHTML.java:117) 
~[?:?]
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:172) ~[?:?]
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) ~[?:?]
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) ~[?:?]
at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) ~[?:?]
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:228)
 ~[?:?]
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
 ~[?:?]
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
 ~[?:?]
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2576) ~[?:?]
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:799) 
~[?:?]
{noformat}



was (Author: talli...@mitre.org):
I'm seeing similar behavior in Solr at least back to 8.3.1 but with different 
classes, e.g.:

{noformat}
java.lang.NoClassDefFoundError: Could not initialize class 
org.apache.pdfbox.pdmodel.font.PDType1Font
at 
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62) 
~[?:?]
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:146) 
~[?:?]
at 
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
 ~[?:?]
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:848)
 ~[?:?]
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:503)
 ~[?:?]
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:477)
 ~[?:?]
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:150)
 ~[?:?]
at 
org.apache.pdfbox.text.LegacyPDFStreamEngine.processPage(LegacyPDFStreamEngine.java:139)
 ~[?:?]
at 
org.apache.pdfbox.text.PDFTextStripper.processPage(PDFTextStripper.java:391) 
~[?:?]
at org.apache.tika.parser.pdf.PDF2XHTML.processPage(PDF2XHTML.java:147) 
~[?:?]
at 
org.apache.pdfbox.text.PDFTextStripper.processPages(PDFTextStripper.java:319) 
~[?:?]
at 
org.apache.pdfbox.text.PDFTextStripper.writeText(PDFTextStripper.java:266) 
~[?:?]
at org.apache.tika.parser.pdf.PDF2XHTML.process(PDF2XHTML.java:117) 
~[?:?]
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:172) ~[?:?]
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) ~[?:?]
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) ~[?:?]
at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) ~[?:?]
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:228)
 ~[?:?]
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
 ~[?:?]
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
 ~[?:?]
at org.apache.solr.core.SolrCore.execute(S

[jira] [Commented] (LUCENE-9089) FST.Builder with fluent-style constructor

[ASF subversion and git services (Jira)]

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

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

Commit 1812b367abad0fe9f123fd8f9ffb11c7dc155404 in lucene-solr's branch 
refs/heads/gradle-master from Bruno Roustant
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1812b36 ]

LUCENE-9089: FST Builder renamed FSTCompiler with fluent-style Builder.

Closes #1070


> FST.Builder with fluent-style constructor
> -
>
> Key: LUCENE-9089
> URL: https://issues.apache.org/jira/browse/LUCENE-9089
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Bruno Roustant
>Assignee: Bruno Roustant
>Priority: Minor
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> A first step in a try to make the FST code easier to read and evolve. This 
> step is just about the FST Builder constructor.
> By making it fluent, the many calls to it are simplified and it becomes easy 
> to spot the intent and special param tuning.
> No functional change.



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

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

[jira] [Commented] (SOLR-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison commented on SOLR-14054:


[~tilman], I'm still getting this issue with PDFBox 2.0.17 when packaged in 
Solr.  Is this more likely to be a Solr issue or a PDFBox issue?

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
>
> We just released 1.23.  Let's upgrade Tika.



--
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-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison commented on SOLR-14054:


I can replicate this reliably on Ubuntu 19.10, but I'm not seeing this issue on 
Mojave 10.14.6.

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
>
> We just released 1.23.  Let's upgrade Tika.



--
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] iverase commented on issue #587: LUCENE-8707: Add LatLonShape and XYShape distance query

[GitBox]

iverase commented on issue #587: LUCENE-8707: Add LatLonShape and XYShape 
distance query
URL: https://github.com/apache/lucene-solr/pull/587#issuecomment-565489734
 
 
   I went through another iteration and built those queries using the 
Component2D abstraction. I think it is looking pretty good, LatLonShape 
supports circles that goes over the date line.
   
   @nknize @jpountz feedback would be great!


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] HoustonPutman commented on a change in pull request #1071: SOLR-14003: Refactor code to avoid reading state from Replica/Slic

[GitBox]

HoustonPutman commented on a change in pull request #1071: SOLR-14003: Refactor 
code to avoid reading state from Replica/Slic
URL: https://github.com/apache/lucene-solr/pull/1071#discussion_r357705214
 
 

 ##
 File path: 
solr/solrj/src/java/org/apache/solr/client/solrj/cloud/ShardStateProvider.java
 ##
 @@ -0,0 +1,56 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.client.solrj.cloud;
+
+import org.apache.solr.common.cloud.Replica;
+import org.apache.solr.common.cloud.Slice;
+/**An implementation that fetches the state of each replica/slice and leaders 
of shards in a collection.
+ * The state is embedded with other topology information in state.json in the 
original SolrCLoud design.
+ * But, it is possible to have another implementation where the state and 
leader information can be stored and read
+ * from other places.
+ *
+ */
+public interface ShardStateProvider {
+
+  /**Get the state of  a given {@link Replica}
+   */
+  Replica.State getState(Replica replica);
+
+  /**Get the leader {@link Replica} of the shard
+   */
+  Replica getLeader(Slice slice);
+
+  /**Get the leader of the slice. Wait for one if there is no leader
+   * @param timeout how much time to wait for a leader to com eup. -1 means 
the default value will be used
+   * Throws an {@link InterruptedException} if interrupted in between
+   */
+  Replica getLeader(Slice slice, int timeout) throws InterruptedException;
+
+
+  Replica getLeader(String collection, String slice, int timeout) throws 
InterruptedException;
+
+
+  /**CHeck if the replica is active
+   *
+   */
+  boolean isActive(Replica replica);
 
 Review comment:
   I think that this needs additional documentation stating whether the method 
returns true if the node which the replica is on is live or not.


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


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] HoustonPutman commented on a change in pull request #1071: SOLR-14003: Refactor code to avoid reading state from Replica/Slic

[GitBox]

HoustonPutman commented on a change in pull request #1071: SOLR-14003: Refactor 
code to avoid reading state from Replica/Slic
URL: https://github.com/apache/lucene-solr/pull/1071#discussion_r357706730
 
 

 ##
 File path: solr/core/src/test/org/apache/solr/cloud/SyncSliceTest.java
 ##
 @@ -217,11 +218,13 @@ private void waitTillAllNodesActive() throws Exception {
   ZkStateReader zkStateReader = cloudClient.getZkStateReader();
   ClusterState clusterState = zkStateReader.getClusterState();
   DocCollection collection1 = clusterState.getCollection("collection1");
+  ShardStateProvider ssp = 
zkStateReader.getShardStateProvider(collection1.getName());
+
   Slice slice = collection1.getSlice("shard1");
   Collection replicas = slice.getReplicas();
   boolean allActive = true;
   for (Replica replica : replicas) {
-if (!clusterState.liveNodesContain(replica.getNodeName()) || 
replica.getState() != Replica.State.ACTIVE) {
+if (!clusterState.liveNodesContain(replica.getNodeName()) || 
ssp.getState(replica)!= Replica.State.ACTIVE) {
 
 Review comment:
   Why not use a `!ssp.isActive(replica)`?
   
   I see inconsistent usage of this logic throughout.


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-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison commented on SOLR-14054:


> but /contrib/extraction/lib might not be in the core classloader?

Makes sense...I'm not able to replicate this problem in unit tests.  Do you 
know if classloading works differently in unit tests?

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
>
> We just released 1.23.  Let's upgrade Tika.



--
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-14054) Upgrade Tika to 1.23

[Kevin Risden (Jira)]

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

Kevin Risden commented on SOLR-14054:
-

{quote}I can replicate this reliably on Ubuntu 19.10, but I'm not seeing this 
issue on Mojave 10.14.6.{quote}

So I wouldn't expect classloader issues to come up in Java and behave 
differently on different OS. Maybe different Java versions?

{quote}Do you know if classloading works differently in unit tests?{quote}

My gut says yes but I don't know for sure. 

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
>
> We just released 1.23.  Let's upgrade Tika.



--
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-14054) Upgrade Tika to 1.23

[Kevin Risden (Jira)]

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

Kevin Risden commented on SOLR-14054:
-

Are the reproduction steps relatively easily (ie: scriptable?) Do you have 
reproduction steps? Maybe I can try to help run and help narrow it down?

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
>
> We just released 1.23.  Let's upgrade Tika.



--
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-11516) Unified highlighter with word separator never gives context to the left

[Jira]

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

Nándor Mátravölgyi commented on SOLR-11516:
---

As previously stated the UnifiedHighlighter always returns full sentences (with 
SENTENCE bs.type), effectively not adhering to the fragsize parameter. Changing 
the breakiterator type to WORD makes the fragsize work as expected, but the 
matches are not "centered" in the snippets, making their context much less 
apparent in some cases.

The trimming on the client-side is relatively a bad solution in my opinion. 
Let's say I receive a highlight that is several times longer than I want, but 
the matches are very unevenly distributed because of a long sentence: 
OXOXXX (imagine X represents the matches and O the text around them). 
The client (to truly be correct) has to parse the highlight for the pre-post 
tags and strip the middle of the text. In a more primitive solution the 
highlight would be bluntly truncated and the valuable matches at the end are 
lost to the client. This work is redundant and wasteful if solr could do it 
like in the other highlighters.

I really wanted to have the fragsize be around what I specified even with much 
longer sentences, so I've spent some time analyzing the code and designing 
possible changes.

The UnifiedHighlighter chains the selected breakiterator instance requested by 
the hl.bs.type parameter with a LengthGoalBreakIterator. (unless fragsize <= 1 
or type == WHOLE) It is actually the LengthGoalBreakIterator that decides what 
parts should be in the snippet around the actual match.

Currently this class always starts the snippet from the first break before the 
match indicated by the wrapped iterator, and may only extend the snippet beyond 
the match until fragsize is reached.

There is a "closestTo" mode implemented in it, but it's always starts like the 
used one and it is not selectable because it would require some additional 
missing parameter. ([view on 
github|https://github.com/apache/lucene-solr/blob/e5df183a42967c0eb79b5c2c65cd3ab618318f23/solr/core/src/java/org/apache/solr/highlight/UnifiedSolrHighlighter.java#L330])

So far I can see two ways to improve this:
 # Improve the LengthGoalBreakIterator to have a "centerAround" mode. This has 
the benefit of working with all other hl.bs.types. Even though it would mostly 
be meaningful for SEPARATOR and WORD. In SENTENCE mode a great enough fragsize 
could include a preceding sentence in the snippet as well. To use this mode a 
new parameter has to be created. Something like "hl.bs.snippetAlignment" maybe, 
which could have the values of "min" - current behavior, "closest" - currently 
unreachable and "center" - the proposed behavior.
 # Make a new hl.bs.type, AROUND_MATCH maybe and create a different 
breakiterator wrapper to be used instead of the LengthGoalBreakIterator. This 
would wrap a WORD brakeiterator thus producing similar results to the other 
highlighters.

One question is if the passage (ultimately snippet) extractor algorithm in 
FieldHighlighter needs to change. Currently because no breakiterator looks 
before the match for a passage start position, it is guaranteed that the 
passages will have no overlap. This is something that would not be the case 
after the changes, and may also need some work. (interestingly the fastVerctor 
highlighter can produce slight overlaps if the matches are dense enough, while 
the original will not)

I'm pretty sure either can be done with minimal overhead since all data is 
already available. The algorithms just need to make different decisions where 
to slice the strings. I'm willing to work on this, so please share your ideas.

> Unified highlighter with word separator never gives context to the left
> ---
>
> Key: SOLR-11516
> URL: https://issues.apache.org/jira/browse/SOLR-11516
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 6.4, 7.1
>Reporter: Tim Retout
>Priority: Major
>
> When using the unified highlighter with hl.bs.type=WORD, I am not able to get 
> context to the left of the matches returned; only words to the right of each 
> match are shown.  I see this behaviour on both Solr 6.4 and Solr 7.1.
> Without context to the left of a match, the highlighted snippets are much 
> less useful for understanding where the match appears in a document.
> As an example, using the techproducts data with Solr 7.1, given a search for 
> "apple", highlighting the "features" field:
> http://localhost:8983/solr/techproducts/select?hl.fl=features&hl=on&q=apple&hl.bs.type=WORD&hl.fragsize=30&hl.method=unified
> I see this snippet:
> "Apple Lossless, H.264 video"
> Note that "Apple" is anchored to the left.  Compare 

[jira] [Commented] (SOLR-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison commented on SOLR-14054:


[~tilman]...please ignore...PDFBox issues appear to be spurious/user error.

[~krisden] will send reproduction steps shortly.  Thank you!


> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
>
> We just released 1.23.  Let's upgrade Tika.



--
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-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison updated SOLR-14054:
---
Attachment: test-documents.7z

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
> Attachments: test-documents.7z
>
>
> We just released 1.23.  Let's upgrade Tika.



--
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-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison updated SOLR-14054:
---
Attachment: tika-integration-example-9.0.0-SNAPSHOT.tgz

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
> Attachments: test-documents.7z, 
> tika-integration-example-9.0.0-SNAPSHOT.tgz
>
>
> We just released 1.23.  Let's upgrade Tika.



--
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-14026) Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14026:


Commit 8278886966c6da7379cf9c9505f7859b832c4ab3 in lucene-solr's branch 
refs/heads/master from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8278886 ]

SOLR-14026: Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2


> Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2
> -
>
> Key: SOLR-14026
> URL: https://issues.apache.org/jira/browse/SOLR-14026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-14026.patch, SOLR-14026.patch, SOLR-14026.patch
>
>
> Prompted by the linked JIRA.



--
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-14026) Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2

[Erick Erickson (Jira)]

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

Erick Erickson updated SOLR-14026:
--
Attachment: SOLR-14026.patch

> Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2
> -
>
> Key: SOLR-14026
> URL: https://issues.apache.org/jira/browse/SOLR-14026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-14026.patch, SOLR-14026.patch, SOLR-14026.patch
>
>
> Prompted by the linked JIRA.



--
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-14026) Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2

[Erick Erickson (Jira)]

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

Erick Erickson updated SOLR-14026:
--
Status: Open  (was: Patch Available)

> Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2
> -
>
> Key: SOLR-14026
> URL: https://issues.apache.org/jira/browse/SOLR-14026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-14026.patch, SOLR-14026.patch, SOLR-14026.patch
>
>
> Prompted by the linked JIRA.



--
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-14079) SPLITSHARD splitByPrefix doesn't work in async mode

[Ilan Ginzburg (Jira)]

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

Ilan Ginzburg commented on SOLR-14079:
--

Ok makes sense to use the patch as is. Didn't realize the id's were for tests 
(looked really too quickly at the diff).

I'll try to understand if there's a general issue with the way async calls are 
managed between nodes and the overseer. I suppose there is because the 
implementation for smart shard splits did work in some instances and did fail 
in other. A new Jira is indeed appropriate in that case.

> SPLITSHARD splitByPrefix doesn't work in async mode
> ---
>
> Key: SOLR-14079
> URL: https://issues.apache.org/jira/browse/SOLR-14079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-14079.patch
>
>
> If you specify async=whatever in conjunction with splitByPrefix, the ranges 
> are calculated by the shard leader, but that information does not make it 
> back to the overseer and the split proceeds to just split down the middle.



--
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-13778) Windows JDK SSL Test Failure trend: SSLException: Software caused connection abort: recv failed

[Chris M. Hostetter (Jira)]

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

Chris M. Hostetter commented on SOLR-13778:
---

{quote}What do you think - should we just add SSLException to the retry list?
{quote}
I have no idea ... why/what exceptions are considered retry-able isn't 
something i really understand.

All of the logic in SolrHttpRequestRetryHandler appears to have been added new 
(not refactored from anywhere else) by [~markrmil...@gmail.com] in SOLR-8450 - 
but i don't really see a discussion of why that specific list of exceptions was 
chosen.

/cc [~shalin]  & [~caomanhdat]  as well

 

TBH: I've re-read Dawid's analysis twice and I'm still not really understanding:
 * why "windows>=jdk11" is throwing a different (or differently wrapped?) 
exception then "windows 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: dumps-LegacyCloud.zip, logs-2019-12-12-1.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

[jira] [Moved] (LUCENE-9093) Unified highlighter with word separator never gives context to the left

[David Smiley (Jira)]

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

David Smiley moved SOLR-11516 to LUCENE-9093:
-

  Component/s: (was: highlighter)
   modules/highlighter
  Key: LUCENE-9093  (was: SOLR-11516)
Lucene Fields: New
Affects Version/s: (was: 7.1)
   (was: 6.4)
   Issue Type: Improvement  (was: Bug)
  Project: Lucene - Core  (was: Solr)

> Unified highlighter with word separator never gives context to the left
> ---
>
> Key: LUCENE-9093
> URL: https://issues.apache.org/jira/browse/LUCENE-9093
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Tim Retout
>Priority: Major
>
> When using the unified highlighter with hl.bs.type=WORD, I am not able to get 
> context to the left of the matches returned; only words to the right of each 
> match are shown.  I see this behaviour on both Solr 6.4 and Solr 7.1.
> Without context to the left of a match, the highlighted snippets are much 
> less useful for understanding where the match appears in a document.
> As an example, using the techproducts data with Solr 7.1, given a search for 
> "apple", highlighting the "features" field:
> http://localhost:8983/solr/techproducts/select?hl.fl=features&hl=on&q=apple&hl.bs.type=WORD&hl.fragsize=30&hl.method=unified
> I see this snippet:
> "Apple Lossless, H.264 video"
> Note that "Apple" is anchored to the left.  Compare with the original 
> highlighter:
> http://localhost:8983/solr/techproducts/select?hl.fl=features&hl=on&q=apple&hl.fragsize=30
> And the match has context either side:
> ", Audible, Apple Lossless, H.264 video"
> (To complicate this, in general I am not sure that the unified highlighter is 
> respecting the hl.fragsize parameter, although [SOLR-9935] suggests support 
> was added.  I included the hl.fragsize param in the unified URL too, but it's 
> making no difference unless set to 0.)



--
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] msokolov commented on issue #1070: LUCENE-9089: FST Builder fluent-style constructor.

[GitBox]

msokolov commented on issue #1070: LUCENE-9089: FST Builder fluent-style 
constructor.
URL: https://github.com/apache/lucene-solr/pull/1070#issuecomment-565534583
 
 
   I was confused at first, since FST.Arc is used elsewhere, but that's right 
(fst).Builder.Arc is not - it should be encapsulated


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-14026) Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14026:


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

SOLR-14026: Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2

(cherry picked from commit 8278886966c6da7379cf9c9505f7859b832c4ab3)


> Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2
> -
>
> Key: SOLR-14026
> URL: https://issues.apache.org/jira/browse/SOLR-14026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-14026.patch, SOLR-14026.patch, SOLR-14026.patch
>
>
> Prompted by the linked JIRA.



--
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-14026) Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14026:


Commit 2feeb88c294030be654183d22a8e503bbbf8b293 in lucene-solr's branch 
refs/heads/master from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2feeb88 ]

SOLR-14026: Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2, moved to 
8.5 in CHANGES.txt


> Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2
> -
>
> Key: SOLR-14026
> URL: https://issues.apache.org/jira/browse/SOLR-14026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-14026.patch, SOLR-14026.patch, SOLR-14026.patch
>
>
> Prompted by the linked JIRA.



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

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

[jira] [Created] (SOLR-14080) Replace all legacy Abstract(Full)DistribZkTestBase tests with SolrCloudTestCase equivilents

[Chris M. Hostetter (Jira)]

Chris M. Hostetter created SOLR-14080:
-

 Summary: Replace all legacy Abstract(Full)DistribZkTestBase tests 
with SolrCloudTestCase equivilents
 Key: SOLR-14080
 URL: https://issues.apache.org/jira/browse/SOLR-14080
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Chris M. Hostetter


AbstractDistribZkTestBase and in particular AbstractFullDistribZkTestBase are 
antiquated - and really just plan terrible and convoluted - "plumbing" for 
writing distributed tests, that "sort of kind of" emulate SolrCloud, but also 
have a lot of other crap & cruft in them that can be 
abused/missused/missunderstood.  Any tests using them should be re-written to 
subclass SolrCloudTestCase

This issue should serve as a tracking point for linking other issues and/or 
sub-tasks targeting individual test classes and/or refactoring common 
functionality to make tests easy to port.



--
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-14026) Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14026:


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

SOLR-14026: Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2, moved to 
8.5 in CHANGES.txt


> Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2
> -
>
> Key: SOLR-14026
> URL: https://issues.apache.org/jira/browse/SOLR-14026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-14026.patch, SOLR-14026.patch, SOLR-14026.patch
>
>
> Prompted by the linked JIRA.



--
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-14080) Replace all legacy Abstract(Full)DistribZkTestBase tests with SolrCloudTestCase equivilents

[Chris M. Hostetter (Jira)]

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

Chris M. Hostetter commented on SOLR-14080:
---

I should point out, in an ideal world ever subclass of 
BaseDistributedSearchTestCase should be ported over to a SolrCLoudTestCase, but 
at least BaseDistributedSearchTestCase is a little simpler in what it does – 
and re-writting all of those tests (that heavily depend on comparing the 
control collection with the "sharded" collection) will likely require a lot 
more work to "get right".

BaseDistributedSearchTestCase also aren't quite as finicky as the 
AbstractDistribZkTestBase tests because of how much simpler the overall 
plumbing is ... in particular, i found this note in my "TODO" list from a while 
back...
{noformat}
TODO: AbstractFullDistribZkTestBase is a fucking abomination that needs to die.
TODO: the way it creates collections causes every replica to be in recovery 
from the moment it's created.
TODO: in general all tests using this base class should just be re-written from 
scratch using MiniSolrCloud

{noformat}
...i don't even remember what exactly this was refering to, but I trust myself 
that it's true (at least for whatever convoluted default way 
AbstractFullDistribZkTestBase has for creating collections)

 

> Replace all legacy Abstract(Full)DistribZkTestBase tests with 
> SolrCloudTestCase equivilents
> ---
>
> Key: SOLR-14080
> URL: https://issues.apache.org/jira/browse/SOLR-14080
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Chris M. Hostetter
>Priority: Major
>
> AbstractDistribZkTestBase and in particular AbstractFullDistribZkTestBase are 
> antiquated - and really just plan terrible and convoluted - "plumbing" for 
> writing distributed tests, that "sort of kind of" emulate SolrCloud, but also 
> have a lot of other crap & cruft in them that can be 
> abused/missused/missunderstood.  Any tests using them should be re-written to 
> subclass SolrCloudTestCase
> This issue should serve as a tracking point for linking other issues and/or 
> sub-tasks targeting individual test classes and/or refactoring common 
> functionality to make tests easy to port.



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

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

[jira] [Created] (SOLR-14081) rewrite FullSolrCloudDistribCmdsTest to extend SolrCloudTestCase

[Chris M. Hostetter (Jira)]

Chris M. Hostetter created SOLR-14081:
-

 Summary: rewrite FullSolrCloudDistribCmdsTest to extend 
SolrCloudTestCase
 Key: SOLR-14081
 URL: https://issues.apache.org/jira/browse/SOLR-14081
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Chris M. Hostetter






--
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-9089) FST.Builder with fluent-style constructor

[Bruno Roustant (Jira)]

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

Bruno Roustant resolved LUCENE-9089.

Resolution: Fixed

> FST.Builder with fluent-style constructor
> -
>
> Key: LUCENE-9089
> URL: https://issues.apache.org/jira/browse/LUCENE-9089
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Bruno Roustant
>Assignee: Bruno Roustant
>Priority: Minor
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> A first step in a try to make the FST code easier to read and evolve. This 
> step is just about the FST Builder constructor.
> By making it fluent, the many calls to it are simplified and it becomes easy 
> to spot the intent and special param tuning.
> No functional change.



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

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

[jira] [Updated] (SOLR-14081) rewrite FullSolrCloudDistribCmdsTest to extend SolrCloudTestCase

[Chris M. Hostetter (Jira)]

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

Chris M. Hostetter updated SOLR-14081:
--
Attachment: SOLR-14081.patch
  Assignee: Chris M. Hostetter
Status: Open  (was: Open)

attaching a starting point that:
 * rips out all the dead/commented out code
 * ports the basic logic over to SolrCloudTestCase
 ** eliminating any comparisons with "control" collection and using specific 
asserts as well
 * implements a new more generalized utilitied for "checking shard consistency"
 ** that should probably begeneralized even more and refactored into 
CloudInspectUtil

I still want to beast this more, but first {{testThatCantForwardToLeaderFails}} 
really needs to be re-written ... as is it's not really testing anything useful.

> rewrite FullSolrCloudDistribCmdsTest to extend SolrCloudTestCase
> 
>
> Key: SOLR-14081
> URL: https://issues.apache.org/jira/browse/SOLR-14081
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14081.patch
>
>




--
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-9089) FST.Builder with fluent-style constructor

[Bruno Roustant (Jira)]

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

Bruno Roustant updated LUCENE-9089:
---
Fix Version/s: master (9.0)

> FST.Builder with fluent-style constructor
> -
>
> Key: LUCENE-9089
> URL: https://issues.apache.org/jira/browse/LUCENE-9089
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Bruno Roustant
>Assignee: Bruno Roustant
>Priority: Minor
> Fix For: master (9.0)
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> A first step in a try to make the FST code easier to read and evolve. This 
> step is just about the FST Builder constructor.
> By making it fluent, the many calls to it are simplified and it becomes easy 
> to spot the intent and special param tuning.
> No functional change.



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

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

[jira] [Commented] (SOLR-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison commented on SOLR-14054:


# checkout https://github.com/tballison/lucene-solr/tree/jira/SOLR-14054
# cd solr ... ant package
# unzip the shiny new Solr
# put the attached collection conf where it belongs
# start solr 
# {{curl 
'http://localhost:8983/solr/tika-integration-example/update/extract?literal.id=doc1&commit=true'
 -F "myfile=@test-documents.7z"}}

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
> Attachments: test-documents.7z, 
> tika-integration-example-9.0.0-SNAPSHOT.tgz
>
>
> We just released 1.23.  Let's upgrade Tika.



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

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

[jira] [Comment Edited] (SOLR-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison edited comment on SOLR-14054 at 12/13/19 6:20 PM:
--

# clone master or my personal issue branch: 
https://github.com/tballison/lucene-solr/tree/jira/SOLR-14054 (tukaani issue 
happens in both).
# cd solr ... ant package
# unzip the shiny new Solr
# put the attached collection conf where it belongs
# start solr 
# {{curl 
'http://localhost:8983/solr/tika-integration-example/update/extract?literal.id=doc1&commit=true'
 -F "myfile=@test-documents.7z"}}


was (Author: talli...@mitre.org):
# checkout https://github.com/tballison/lucene-solr/tree/jira/SOLR-14054
# cd solr ... ant package
# unzip the shiny new Solr
# put the attached collection conf where it belongs
# start solr 
# {{curl 
'http://localhost:8983/solr/tika-integration-example/update/extract?literal.id=doc1&commit=true'
 -F "myfile=@test-documents.7z"}}

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
> Attachments: test-documents.7z, 
> tika-integration-example-9.0.0-SNAPSHOT.tgz
>
>
> We just released 1.23.  Let's upgrade Tika.



--
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] ctargett commented on a change in pull request #1077: SOLR-14069: Ref guide: overhaul: resources, libs, plugins, config-sets

[GitBox]

ctargett commented on a change in pull request #1077: SOLR-14069: Ref guide: 
overhaul: resources, libs, plugins, config-sets
URL: https://github.com/apache/lucene-solr/pull/1077#discussion_r357795985
 
 

 ##
 File path: solr/solr-ref-guide/src/solr-plugins.adoc
 ##
 @@ -17,8 +20,36 @@
 // specific language governing permissions and limitations
 // under the License.
 
-Solr allows you to load custom code to perform a variety of tasks within Solr, 
from custom Request Handlers to process your searches, to custom Analyzers and 
Token Filters for your text field. You can even load custom Field Types. These 
pieces of custom code are called _plugins_.
+One of Solr's strengths is providing a rich platform of functionality with the 
option of adding your own custom components running within Solr.
+Solr calls such components *plugins* when the implementation is configurable.
 
 Review comment:
   All our HTML pages treat the opening paragraph of a page as the "lede" and 
CSS makes it larger. For this reason we should avoid large blocks and try to 
open the page with a sentence that summarizes the feature/function if possible 
(it can be hard). In this case, the first sentence is rather perfect, so I'd 
suggest adding a new line here to separate the lede from the next batch of 
information which starts to get into the details.


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] ctargett commented on a change in pull request #1077: SOLR-14069: Ref guide: overhaul: resources, libs, plugins, config-sets

[GitBox]

ctargett commented on a change in pull request #1077: SOLR-14069: Ref guide: 
overhaul: resources, libs, plugins, config-sets
URL: https://github.com/apache/lucene-solr/pull/1077#discussion_r357738240
 
 

 ##
 File path: solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
 ##
 @@ -1,5 +1,16 @@
 = Configuring solrconfig.xml
-:page-children: datadir-and-directoryfactory-in-solrconfig, 
resource-and-plugin-loading, schema-factory-definition-in-solrconfig, 
indexconfig-in-solrconfig, requesthandlers-and-searchcomponents-in-solrconfig, 
initparams-in-solrconfig, updatehandlers-in-solrconfig, 
query-settings-in-solrconfig, requestdispatcher-in-solrconfig, 
update-request-processors, codec-factory
+:page-children: datadir-and-directoryfactory-in-solrconfig, \
 
 Review comment:
   OK, +1


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] ctargett commented on a change in pull request #1077: SOLR-14069: Ref guide: overhaul: resources, libs, plugins, config-sets

[GitBox]

ctargett commented on a change in pull request #1077: SOLR-14069: Ref guide: 
overhaul: resources, libs, plugins, config-sets
URL: https://github.com/apache/lucene-solr/pull/1077#discussion_r357796079
 
 

 ##
 File path: solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
 ##
 @@ -1,5 +1,16 @@
 = Configuring solrconfig.xml
-:page-children: datadir-and-directoryfactory-in-solrconfig, 
resource-and-plugin-loading, schema-factory-definition-in-solrconfig, 
indexconfig-in-solrconfig, requesthandlers-and-searchcomponents-in-solrconfig, 
initparams-in-solrconfig, updatehandlers-in-solrconfig, 
query-settings-in-solrconfig, requestdispatcher-in-solrconfig, 
update-request-processors, codec-factory
+:page-children: datadir-and-directoryfactory-in-solrconfig, \
 
 Review comment:
   OK, +1


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-14054) Upgrade Tika to 1.23

[Robert Muir (Jira)]

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

Robert Muir commented on SOLR-14054:


Hi Tim, I have not tried to reproduce your steps yet, but if Tika is broken in 
master, I think it would be good to open a BUG JIRA issue separate from this.

I am afraid otherwise it gets lost in the noise due to the issue's title of 
UPGRADE

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
> Attachments: test-documents.7z, 
> tika-integration-example-9.0.0-SNAPSHOT.tgz
>
>
> We just released 1.23.  Let's upgrade Tika.



--
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] ctargett commented on issue #1077: SOLR-14069: Ref guide: overhaul: resources, libs, plugins, config-sets

[GitBox]

ctargett commented on issue #1077: SOLR-14069: Ref guide: overhaul: resources, 
libs, plugins, config-sets
URL: https://github.com/apache/lucene-solr/pull/1077#issuecomment-565576323
 
 
   I looked over these, and +1.
   
   I left one comment on solr-plugins.adoc about separating the first sentence 
from the first paragraph from the rest of the paragraph because of the way we 
treat the opening paragraph of each page - both resource-loading.adoc and 
libs.adoc could use a similar change. That's mostly a suggestion, though, if 
you don't feel like making that change I don't think it should hold you up.


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-14080) Replace all legacy Abstract(Full)DistribZkTestBase tests with SolrCloudTestCase equivilents

[Kevin Risden (Jira)]

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

Kevin Risden commented on SOLR-14080:
-

Some jiras that this is probably related to:
* SOLR-3727 - not sure this is valid anymore???
* SOLR-5508
* SOLR-5919
* SOLR-9065

Maybe where your notes came from. 

> Replace all legacy Abstract(Full)DistribZkTestBase tests with 
> SolrCloudTestCase equivilents
> ---
>
> Key: SOLR-14080
> URL: https://issues.apache.org/jira/browse/SOLR-14080
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Chris M. Hostetter
>Priority: Major
>
> AbstractDistribZkTestBase and in particular AbstractFullDistribZkTestBase are 
> antiquated - and really just plan terrible and convoluted - "plumbing" for 
> writing distributed tests, that "sort of kind of" emulate SolrCloud, but also 
> have a lot of other crap & cruft in them that can be 
> abused/missused/missunderstood.  Any tests using them should be re-written to 
> subclass SolrCloudTestCase
> This issue should serve as a tracking point for linking other issues and/or 
> sub-tasks targeting individual test classes and/or refactoring common 
> functionality to make tests easy to port.



--
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-14078) DistribPackageStore tries to write to source tree

[Kevin Risden (Jira)]

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

Kevin Risden commented on SOLR-14078:
-

So this message doesn't show in the Jenkins logs since the tests don't fail. 
The only reason I saw it is because I was running a subset of tests which 
prints out the logs for each test. Specifically was running this but I'm 90% 
sure the error isn't specific to HDFS.

{code:java}
ant test -Dtests.badapples=false -Dtests.nightly=true -Dtests.slow=true 
-Dtests.asserts=true -Dtests.awaitsfix=false -D'testcase=*Hdfs*|*HDFS*|*Hadoop*'
{code}


> DistribPackageStore tries to write to source tree
> -
>
> Key: SOLR-14078
> URL: https://issues.apache.org/jira/browse/SOLR-14078
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Kevin Risden
>Priority: Major
>
> Found while looking at SOLR-14064:
> This doesn't cause the test to fail, but it still is wrong to try to write to 
> the source tree. There are junit temp dirs for the running test. It looks 
> like SOLR_HOME is potentially set incorrectly?
> FWIW I don't think this is specific to TestRecoveryHdfs. It is just where I 
> saw the error.
> {code:java}
> 2> 23044 WARN  (SUITE-TestRecoveryHdfs-seed#[AC80F05AAAD3A298]-worker) [ 
> ] o.a.s.f.DistribPackageStore Unable to create 
> [/Users/risdenk/repos/apache/lucene-solr/solr/core/src/test-files/solr/filestore]
>  directory in SOLR_HOME 
> [/Users/risdenk/repos/apache/lucene-solr/solr/core/src/test-files/solr].  
> Features requiring this directory may fail.
>   2>   => java.security.AccessControlException: access denied 
> ("java.io.FilePermission" 
> "/Users/risdenk/repos/apache/lucene-solr/solr/core/src/test-files/solr/filestore"
>  "write")
>   2>  at 
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>   2> java.security.AccessControlException: access denied 
> ("java.io.FilePermission" 
> "/Users/risdenk/repos/apache/lucene-solr/solr/core/src/test-files/solr/filestore"
>  "write")
>   2>  at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  ~[?:?]
>   2>  at 
> java.security.AccessController.checkPermission(AccessController.java:897) 
> ~[?:?]
>   2>  at java.lang.SecurityManager.checkPermission(SecurityManager.java:322) 
> ~[?:?]
>   2>  at java.lang.SecurityManager.checkWrite(SecurityManager.java:752) ~[?:?]
>   2>  at java.io.File.mkdir(File.java:1323) ~[?:?]
>   2>  at java.io.File.mkdirs(File.java:1355) ~[?:?]
>   2>  at 
> org.apache.solr.filestore.DistribPackageStore.ensurePackageStoreDir(DistribPackageStore.java:476)
>  ~[java/:?]
>   2>  at 
> org.apache.solr.filestore.DistribPackageStore.(DistribPackageStore.java:65)
>  ~[java/:?]
>   2>  at 
> org.apache.solr.filestore.PackageStoreAPI.(PackageStoreAPI.java:77) 
> ~[java/:?]
> {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] (SOLR-14026) Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2

[Erick Erickson (Jira)]

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

Erick Erickson resolved SOLR-14026.
---
Fix Version/s: 8.5
   Resolution: Fixed

> Upgrade Jetty to 9.4.24.v20191120 and dropwizard to 4.1.2
> -
>
> Key: SOLR-14026
> URL: https://issues.apache.org/jira/browse/SOLR-14026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-14026.patch, SOLR-14026.patch, SOLR-14026.patch
>
>
> Prompted by the linked JIRA.



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

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

[jira] [Resolved] (SOLR-14037) Upgrade Dropwizard metrics to 4.1.2

[Erick Erickson (Jira)]

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

Erick Erickson resolved SOLR-14037.
---
Fix Version/s: (was: 8.4)
   8.5
   Resolution: Fixed

Incorporated in SOLR-14026

> Upgrade Dropwizard metrics to 4.1.2
> ---
>
> Key: SOLR-14037
> URL: https://issues.apache.org/jira/browse/SOLR-14037
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.5
>
>




--
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-14077) Hadoop shouldn't need to look for metrics config in user home

[Kevin Risden (Jira)]

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

Kevin Risden commented on SOLR-14077:
-

Found a way to override this and insert our own metrics system. Running through 
HDFS related tests now.

> Hadoop shouldn't need to look for metrics config in user home
> -
>
> Key: SOLR-14077
> URL: https://issues.apache.org/jira/browse/SOLR-14077
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
>
> Remove the need for Hadoop to look for metrics config in user home
> {code:java}
> permission java.io.FilePermission 
> "${user.home}${/}hadoop-metrics2.properties", "read";
> permission java.io.FilePermission 
> "${user.home}${/}hadoop-metrics2-namenode.properties", "read";
> {code}
> https://github.com/apache/lucene-solr/blob/master/lucene/tools/junit4/solr-tests.policy#L39



--
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] magibney commented on issue #892: LUCENE-8972: Add ICUTransformCharFilter, to support pre-tokenizer ICU text transformation

[GitBox]

magibney commented on issue #892: LUCENE-8972: Add ICUTransformCharFilter, to 
support pre-tokenizer ICU text transformation
URL: https://github.com/apache/lucene-solr/pull/892#issuecomment-565597955
 
 
   As discussed above, automatically adding external (top-level analysis chain) 
unicode normalization to compensate for `assumeExternalUnicodeNormalization` 
seems too heavy-handed, and potentially complex/brittle, to be introduced at 
this point as user-facing functionality.
   
   But for _tests_, where we know the specific Transliterators being used, it's 
fine to compensate automatically, esp. given that doing so allows us to benefit 
from randomized testing of the `assumeExternalUnicodeNormalization` arg.
   
   Commit 3f4fcbb is the patch uploaded above by @msokolov. Commit feae28c 
exposes package-private method 
`ICUTransformCharFilter.unicodeNormalizationType(String)` to enable tests to 
properly compensate for randomly flipping the 
`assumeExternalUnicodeNormalization` arg, preserving @msokolov's introduction 
of the randomization of that arg.
   
   In the course of work on commit feae28c, I realized that there are some 
Transliterators (e.g., from the tests, `Latin-Katakana`) that have 
leading/trailing sub-transliterators that effectively perform unicode 
normalization, but are not detected/removed by the 
`assumeExternalUnicodeNormalization` rule modification. In the case of 
`Latin-Katakana`, this is because the sub-transliterators in question are 
themselves composite transliterators). I'm not sure what (if anything) to do 
about this, but commit 92209c5 calls attention to the issue by adding detection 
for this condition, and provides a stub that could be used to log a warning to 
make things easier in the future if this should merit more attention.


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-9093) Unified highlighter with word separator never gives context to the left

[David Smiley (Jira)]

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

David Smiley commented on LUCENE-9093:
--

This is a very thoughtful response [~myusername8].  I'm really glad you are 
willing to contribute :-)

An idea I have thought of before is to try to get more leading context before 
the first word.  Basically compute half the fragsize as the amount of leading 
text we'd like (configurable ratio).  Then keep looping over sub-BreakIterator 
calls to preceding() until we reach this target.  Strictly speaking, the 
BreakIterator generically has no concept of a highlighting "match" but these 
special-purpose BreakIterators are used in the concept of the 
UnifiedHighlighter and know that when preceding() is called, it's at the first 
match of a passage.  WDYT?  Unfortunately I think it would yield Passages that 
overlap, and that subsequent Passages would not contain the matches of the 
previous overlapping passages. :-/. Maybe this could be overcome by 
FieldHighlighter detecting this and adding the pertinent matches from the most 
recent Passage. 

I'm aware that the use of BreakIterator is limiting, constraining our solution 
space.  And it puts undo extra work on us to implement the JDK defined 
abstraction.  Perhaps like the FVH, the UH needs it's own abstraction here.  CC 
[~romseygeek]

> Unified highlighter with word separator never gives context to the left
> ---
>
> Key: LUCENE-9093
> URL: https://issues.apache.org/jira/browse/LUCENE-9093
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Tim Retout
>Priority: Major
>
> When using the unified highlighter with hl.bs.type=WORD, I am not able to get 
> context to the left of the matches returned; only words to the right of each 
> match are shown.  I see this behaviour on both Solr 6.4 and Solr 7.1.
> Without context to the left of a match, the highlighted snippets are much 
> less useful for understanding where the match appears in a document.
> As an example, using the techproducts data with Solr 7.1, given a search for 
> "apple", highlighting the "features" field:
> http://localhost:8983/solr/techproducts/select?hl.fl=features&hl=on&q=apple&hl.bs.type=WORD&hl.fragsize=30&hl.method=unified
> I see this snippet:
> "Apple Lossless, H.264 video"
> Note that "Apple" is anchored to the left.  Compare with the original 
> highlighter:
> http://localhost:8983/solr/techproducts/select?hl.fl=features&hl=on&q=apple&hl.fragsize=30
> And the match has context either side:
> ", Audible, Apple Lossless, H.264 video"
> (To complicate this, in general I am not sure that the unified highlighter is 
> respecting the hl.fragsize parameter, although [SOLR-9935] suggests support 
> was added.  I included the hl.fragsize param in the unified URL too, but it's 
> making no difference unless set to 0.)



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

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

[jira] [Assigned] (LUCENE-9091) UnifiedHighlighter HTML escaping should only escape essentials

[David Smiley (Jira)]

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

David Smiley reassigned LUCENE-9091:


Assignee: David Smiley

> UnifiedHighlighter HTML escaping should only escape essentials
> --
>
> Key: LUCENE-9091
> URL: https://issues.apache.org/jira/browse/LUCENE-9091
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Nándor Mátravölgyi
>Assignee: David Smiley
>Priority: Minor
> Attachments: LUCENE-9091.patch
>
>
> The unified highlighter does not use the 
> *org.apache.lucene.search.highlight.SimpleHTMLEncoder* through 
> *org.apache.solr.highlight.HtmlEncoder*. It has the HTML escaping feature 
> re-implemented and embedded in the 
> *org.apache.lucene.search.uhighlight.DefaultPassageFormatter*.
> The HTML escaping done by the unified highlighter escapes characters that do 
> not need it. This makes the result payload 50%+ more heavy with no benefit.
> Here is a highlight snippet using the original highlighter:
> {noformat}
> A filter that stems words using a Snowball-generated stemmer. 
> Available stemmers & x are listed in org.tartarus.snowball.ext. Note: 
> This filter is aware of the KeywordAttribute.
> {noformat}
> Here is the same highlight snippet using the unified highlighter:
> {noformat}
> A filter that stems words using a Snowball-generated stemmer. Available stemmers & x are listed in org.tartarus.snowball.ext. Note: This filter is aware of the KeywordAttribute.
> {noformat}
> Maybe I'm missing the point why this is done the way it is. If this behaviour 
> is desired for some use-case it should be a separate encoder, and the HTML 
> encoder should only escape the necessary characters.
> Affects all versions of Lucene-Solr since the addition of the 
> UnifiedHighlighter. Here are the lines where the escaping are implemented 
> differently:
>  * [Escaping by the unified 
> highlighter|https://github.com/apache/lucene-solr/blob/2387bb9d60ae44eeeb4fbcb2f2877f46be5303a0/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/DefaultPassageFormatter.java#L132]
>  * [Escaping by the other 
> highlighters|https://github.com/apache/lucene-solr/blob/2387bb9d60ae44eeeb4fbcb2f2877f46be5303a0/lucene/highlighter/src/java/org/apache/lucene/search/highlight/SimpleHTMLEncoder.java#L69]
>  



--
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-14071) Untrusted configsets shouldn't be allowed to use directive

[Cassandra Targett (Jira)]

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

Cassandra Targett commented on SOLR-14071:
--

Do we have any idea what happens to this during upgrades? If I am running Solr 
8.3 and do not have authentication enabled but have a custom configset I 
uploaded that uses the {{}} directive, what happens when I upgrade to 
8.4? Will my configset suddenly stop working?

> Untrusted configsets shouldn't be allowed to use  directive
> 
>
> Key: SOLR-14071
> URL: https://issues.apache.org/jira/browse/SOLR-14071
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.4
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> Allowing untrusted configsets, i.e. those have been uploaded using the 
> configset upload API without authx enabled, to use the  directive can 
> open up possibilities for malicious users to include insecure contribs 
> libraries.
> Whoever wants to use their own libraries can add them to the classpath of 
> Solr (i.e. place them wherever solr-core-*jar resides). For them, the  
> directive won't be necessary anyway.



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

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

[jira] [Assigned] (SOLR-14072) Deprecate plugin loading using runtimelib

[David Smiley (Jira)]

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

David Smiley reassigned SOLR-14072:
---

Assignee: David Smiley

> Deprecate plugin loading using runtimelib
> -
>
> Key: SOLR-14072
> URL: https://issues.apache.org/jira/browse/SOLR-14072
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.4
>
>
> Package management system supercedes the old way of loading jars from blob 
> store using runtimelib. Let us deprecate the old way.



--
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-14072) Deprecate plugin loading using runtimelib

[David Smiley (Jira)]

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

David Smiley commented on SOLR-14072:
-

I will take it.  Expect a PR for review by EOD Saturday; maybe sooner.

I could remove the docs for it as I think we agree that it's replaced and dead. 
 Users could go to a previous version.  There is more to it than one page 
though; API for blob and also API to manipulate runtimeLib in config API.  WDYT?

> Deprecate plugin loading using runtimelib
> -
>
> Key: SOLR-14072
> URL: https://issues.apache.org/jira/browse/SOLR-14072
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.4
>
>
> Package management system supercedes the old way of loading jars from blob 
> store using runtimelib. Let us deprecate the old way.



--
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] risdenk opened a new pull request #1080: SOLR-14077: Hadoop shouldn't need to look for metrics config in user home

[GitBox]

risdenk opened a new pull request #1080: SOLR-14077: Hadoop shouldn't need to 
look for metrics config in user home
URL: https://github.com/apache/lucene-solr/pull/1080
 
 
   


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-14077) Hadoop shouldn't need to look for metrics config in user home

[Kevin Risden (Jira)]

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

Kevin Risden commented on SOLR-14077:
-

Tests look good on Mac.

> Hadoop shouldn't need to look for metrics config in user home
> -
>
> Key: SOLR-14077
> URL: https://issues.apache.org/jira/browse/SOLR-14077
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14077.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Remove the need for Hadoop to look for metrics config in user home
> {code:java}
> permission java.io.FilePermission 
> "${user.home}${/}hadoop-metrics2.properties", "read";
> permission java.io.FilePermission 
> "${user.home}${/}hadoop-metrics2-namenode.properties", "read";
> {code}
> https://github.com/apache/lucene-solr/blob/master/lucene/tools/junit4/solr-tests.policy#L39



--
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-14077) Hadoop shouldn't need to look for metrics config in user home

[Kevin Risden (Jira)]

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

Kevin Risden updated SOLR-14077:

Status: Patch Available  (was: Open)

> Hadoop shouldn't need to look for metrics config in user home
> -
>
> Key: SOLR-14077
> URL: https://issues.apache.org/jira/browse/SOLR-14077
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14077.patch
>
>
> Remove the need for Hadoop to look for metrics config in user home
> {code:java}
> permission java.io.FilePermission 
> "${user.home}${/}hadoop-metrics2.properties", "read";
> permission java.io.FilePermission 
> "${user.home}${/}hadoop-metrics2-namenode.properties", "read";
> {code}
> https://github.com/apache/lucene-solr/blob/master/lucene/tools/junit4/solr-tests.policy#L39



--
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-14077) Hadoop shouldn't need to look for metrics config in user home

[Kevin Risden (Jira)]

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

Kevin Risden updated SOLR-14077:

Attachment: SOLR-14077.patch

> Hadoop shouldn't need to look for metrics config in user home
> -
>
> Key: SOLR-14077
> URL: https://issues.apache.org/jira/browse/SOLR-14077
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14077.patch
>
>
> Remove the need for Hadoop to look for metrics config in user home
> {code:java}
> permission java.io.FilePermission 
> "${user.home}${/}hadoop-metrics2.properties", "read";
> permission java.io.FilePermission 
> "${user.home}${/}hadoop-metrics2-namenode.properties", "read";
> {code}
> https://github.com/apache/lucene-solr/blob/master/lucene/tools/junit4/solr-tests.policy#L39



--
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-14077) Hadoop shouldn't need to look for metrics config in user home

[Kevin Risden (Jira)]

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

Kevin Risden commented on SOLR-14077:
-

PR: https://github.com/apache/lucene-solr/pull/1080

> Hadoop shouldn't need to look for metrics config in user home
> -
>
> Key: SOLR-14077
> URL: https://issues.apache.org/jira/browse/SOLR-14077
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14077.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Remove the need for Hadoop to look for metrics config in user home
> {code:java}
> permission java.io.FilePermission 
> "${user.home}${/}hadoop-metrics2.properties", "read";
> permission java.io.FilePermission 
> "${user.home}${/}hadoop-metrics2-namenode.properties", "read";
> {code}
> https://github.com/apache/lucene-solr/blob/master/lucene/tools/junit4/solr-tests.policy#L39



--
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-13975) ConcurrentUpdateSolrClient connection stall prevention

[David Smiley (Jira)]

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

David Smiley commented on SOLR-13975:
-

Please ask for a code review next time; okay?  This is some complex code in our 
codebase; I've wrangled with it before.  Also, using a GitHub PR is more 
conducive to invite peer examination.

My main comment on what you have here is code duplication.  There was a fair 
amount of it there already, granted, but you added more.  IntelliJ points this 
out to me.

> ConcurrentUpdateSolrClient connection stall prevention
> --
>
> Key: SOLR-13975
> URL: https://issues.apache.org/jira/browse/SOLR-13975
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3, 8.4
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13975.patch, SOLR-13975.patch
>
>
> When a Solr process, which hosts replicas of a collection, is suspended - 
> that is, the OS process is suspended using eg. {{kill -STOP }} - a long 
> stall may occur in CUSC until a socket timeout is reached.
> During this stall updates from the leader are not forwarded to any replica, 
> even though other replicas are still active and can receive updates.  If the 
> sender uses CUSC (eg. via {{CloudSolrClient}}) then it becomes stalled 
> because the leader stops processing updates, too.
> This situation is caused by several issues:
> * when a process is suspended its sockets remain open - so there is no 
> immediate disconnect as if the process died, but the process becomes 
> unresponsive. Eventually, a socket timeout will be reached 
> (distribUpdateSoTimeout) - but in the default version of {{solr.xml}} this is 
> set to 10 min. During this time all indexing to that shard will be stuck.
> * there are several infinite {{for}} loops in CUSC (eg. in 
> {{blockUntilFinished}}, {{waitForEmptyQueue}} and even in {{request}}), which 
> rely either on the relatively quick success of the call or an exception to be 
> thrown. However, in this situation neither happens quickly - the call is 
> stuck waiting for the remote end until soTimeout expires.
> This issue proposes to add a stall prevention logic, which would break these 
> infinite loops long before the socket timeout occurs based on the progress of 
> the queue processing.
> This is a follow-up to SOLR-13896.



--
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-14054) Upgrade Tika to 1.23

[Tim Allison (Jira)]

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

Tim Allison commented on SOLR-14054:


Thank you, Robert!  If we can get confirmation that I'm not doing something 
stupid -- that this really is a problem -- I'll open a new ticket.  I need to 
do some more investigation.

> Upgrade Tika to 1.23
> 
>
> Key: SOLR-14054
> URL: https://issues.apache.org/jira/browse/SOLR-14054
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Minor
> Attachments: test-documents.7z, 
> tika-integration-example-9.0.0-SNAPSHOT.tgz
>
>
> We just released 1.23.  Let's upgrade Tika.



--
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-7146) MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for /live_nodes

[Rahul (Jira)]

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

Rahul commented on SOLR-7146:
-

I am upgrading cdh 5.13.x to 6.3.1 and i am facing similar issue... i am newbie 
with solr, can you please guide me?

 

2019-12-13 22:00:39,237 INFO (qtp398110318-17)-o.a.s.s.HttpSolrCall: 
[admin] webapp=null path=/admin/collections 
params=\{action=CLUSTERSTATUS&wt=json} status=500 QTime=8
2019-12-13 22:00:39,237 ERROR (qtp398110318-17)-o.a.s.s.HttpSolrCall: 
null:org.apache.zookeeper.KeeperException$NoNodeException: *KeeperErrorCode = 
NoNode for /live_nodes*

> MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for 
> /live_nodes
> 
>
> Key: SOLR-7146
> URL: https://issues.apache.org/jira/browse/SOLR-7146
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 5.3, 6.0
>
> Attachments: SOLR-7146.patch, SOLR-7146v2.patch
>
>
> MiniSolrCloudCluster based tests can fail with the following exception:
> {code}
> org.apache.solr.common.cloud.ZooKeeperException: 
>   at 
> __randomizedtesting.SeedInfo.seed([3F3D838A8ADC9385:F153ADFBF163EC6D]:0)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:463)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:763)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
>   at 
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:193)
>   at 
> org.apache.solr.handler.component.TestTwoPhaseDistributedQuery.testNoExtraFieldsRequestedFromShardsInPhaseOne(TestTwoPhaseDistributedQuery.java:79)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.

[jira] [Commented] (SOLR-7146) MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for /live_nodes

[Kevin Risden (Jira)]

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

Kevin Risden commented on SOLR-7146:


[~pr.rahul] commenting on a very old jira isn't an effective way to get help. 
Since you mention CDH it is better to open a Cloudera support case. Another 
option is the solr-user mailing list [1] but again that is for Apache Solr 
typically.

[1] https://lucene.apache.org/solr/community.html#mailing-lists-irc

> MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for 
> /live_nodes
> 
>
> Key: SOLR-7146
> URL: https://issues.apache.org/jira/browse/SOLR-7146
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 5.3, 6.0
>
> Attachments: SOLR-7146.patch, SOLR-7146v2.patch
>
>
> MiniSolrCloudCluster based tests can fail with the following exception:
> {code}
> org.apache.solr.common.cloud.ZooKeeperException: 
>   at 
> __randomizedtesting.SeedInfo.seed([3F3D838A8ADC9385:F153ADFBF163EC6D]:0)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:463)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:763)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
>   at 
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:193)
>   at 
> org.apache.solr.handler.component.TestTwoPhaseDistributedQuery.testNoExtraFieldsRequestedFromShardsInPhaseOne(TestTwoPhaseDistributedQuery.java:79)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(

[jira] [Created] (SOLR-14082) Retrieving match offsets from the highlighter

[Pip Cet (Jira)]

Pip Cet created SOLR-14082:
--

 Summary: Retrieving match offsets from the highlighter
 Key: SOLR-14082
 URL: https://issues.apache.org/jira/browse/SOLR-14082
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: highlighter
Reporter: Pip Cet


I'm still fairly new to Solr; maybe it's already easily possible to do what I'm 
asking for, in which case this is a documentation issue.

I want something more low-level than pre-edited HTML snippets from the 
highlighter: I just want the text offsets of matches so I can do the snippets 
myself, in the application, and link to the highlighted occurences of the 
search terms in the actual document.

It would also be nice to get the scores for matching passages and the actual 
search terms they correspond to. I believe that the Lucene Matches API would 
provide that once LUCENE-9072 is merged.



--
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-7146) MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for /live_nodes

[Rahul (Jira)]

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

Rahul commented on SOLR-7146:
-

Full log

 

 

org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode 
for /live_nodes
 at org.apache.zookeeper.KeeperException.create(KeeperException.java:114)
 at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)
 at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1405)
 at 
org.apache.solr.common.cloud.SolrZkClient.lambda$getData$5(SolrZkClient.java:341)
 at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
 at org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:341)
 at org.apache.solr.common.cloud.SolrZkClient.printLayout(SolrZkClient.java:602)
 at org.apache.solr.cloud.ZkCLI.main(ZkCLI.java:269)
HTTP/1.1 302 Found
Location: http://localhost:8983/solr/
Content-Length: 0

HTTP/1.1 401 Authentication required
WWW-Authenticate: Negotiate
Set-Cookie: hadoop.auth=; HttpOnly
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 265




Error 401 Authentication required

HTTP ERROR 401
Problem accessing /solr/. Reason:
 Authentication required


*Error: A call to SolrCloud WEB APIs failed: HTTP/1.1 401 Authentication 
required WWW-Authenticate: Negotiate Set-Cookie: hadoop.auth=; HttpOnly 
Cache-Control: must-revalidate,no-cache,no-store Content-Type: 
text/html;charset=iso-8859-1 Content-Length: 282 Error 401 
Authentication requiredHTTP ERROR 401  
Problem accessing /solr/admin/collections. Reason:  Authentication 
required   *
*Re-initialization of CDS_COLUMN_CATALOGS FAILED.*
*FAILURE: Not all of the collections were successfully restored.*
*Deleting directory: /tmp/.cmf-c6-solr-bootstrap-collections-1576270359*
*Deleted /tmp/.cmf-c6-solr-bootstrap-collections-1576270359*

> MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for 
> /live_nodes
> 
>
> Key: SOLR-7146
> URL: https://issues.apache.org/jira/browse/SOLR-7146
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 5.3, 6.0
>
> Attachments: SOLR-7146.patch, SOLR-7146v2.patch
>
>
> MiniSolrCloudCluster based tests can fail with the following exception:
> {code}
> org.apache.solr.common.cloud.ZooKeeperException: 
>   at 
> __randomizedtesting.SeedInfo.seed([3F3D838A8ADC9385:F153ADFBF163EC6D]:0)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:463)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:763)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
>   at 
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:193)
>   at 
> org.apache.solr.handler.component.TestTwoPhaseDistributedQuery.testNoExtraFieldsRequestedFromShardsInPhaseOne(TestTwoPhaseDistributedQuery.java:79)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> 

[jira] [Issue Comment Deleted] (SOLR-7146) MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for /live_nodes

[Rahul (Jira)]

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

Rahul updated SOLR-7146:

Comment: was deleted

(was: Full log

 

 

org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode 
for /live_nodes
 at org.apache.zookeeper.KeeperException.create(KeeperException.java:114)
 at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)
 at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1405)
 at 
org.apache.solr.common.cloud.SolrZkClient.lambda$getData$5(SolrZkClient.java:341)
 at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
 at org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:341)
 at org.apache.solr.common.cloud.SolrZkClient.printLayout(SolrZkClient.java:602)
 at org.apache.solr.cloud.ZkCLI.main(ZkCLI.java:269)
HTTP/1.1 302 Found
Location: http://localhost:8983/solr/
Content-Length: 0

HTTP/1.1 401 Authentication required
WWW-Authenticate: Negotiate
Set-Cookie: hadoop.auth=; HttpOnly
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 265




Error 401 Authentication required

HTTP ERROR 401
Problem accessing /solr/. Reason:
 Authentication required


*Error: A call to SolrCloud WEB APIs failed: HTTP/1.1 401 Authentication 
required WWW-Authenticate: Negotiate Set-Cookie: hadoop.auth=; HttpOnly 
Cache-Control: must-revalidate,no-cache,no-store Content-Type: 
text/html;charset=iso-8859-1 Content-Length: 282 Error 401 
Authentication requiredHTTP ERROR 401  
Problem accessing /solr/admin/collections. Reason:  Authentication 
required   *
*Re-initialization of CDS_COLUMN_CATALOGS FAILED.*
*FAILURE: Not all of the collections were successfully restored.*
*Deleting directory: /tmp/.cmf-c6-solr-bootstrap-collections-1576270359*
*Deleted /tmp/.cmf-c6-solr-bootstrap-collections-1576270359*)

> MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for 
> /live_nodes
> 
>
> Key: SOLR-7146
> URL: https://issues.apache.org/jira/browse/SOLR-7146
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 5.3, 6.0
>
> Attachments: SOLR-7146.patch, SOLR-7146v2.patch
>
>
> MiniSolrCloudCluster based tests can fail with the following exception:
> {code}
> org.apache.solr.common.cloud.ZooKeeperException: 
>   at 
> __randomizedtesting.SeedInfo.seed([3F3D838A8ADC9385:F153ADFBF163EC6D]:0)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:463)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:763)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
>   at 
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:193)
>   at 
> org.apache.solr.handler.component.TestTwoPhaseDistributedQuery.testNoExtraFieldsRequestedFromShardsInPhaseOne(TestTwoPhaseDistributedQuery.java:79)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsea

[jira] [Commented] (SOLR-7146) MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for /live_nodes

[Rahul (Jira)]

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

Rahul commented on SOLR-7146:
-

Thank you Kevin, noted.

> MiniSolrCloudCluster based tests can fail with ZooKeeperException NoNode for 
> /live_nodes
> 
>
> Key: SOLR-7146
> URL: https://issues.apache.org/jira/browse/SOLR-7146
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 5.3, 6.0
>
> Attachments: SOLR-7146.patch, SOLR-7146v2.patch
>
>
> MiniSolrCloudCluster based tests can fail with the following exception:
> {code}
> org.apache.solr.common.cloud.ZooKeeperException: 
>   at 
> __randomizedtesting.SeedInfo.seed([3F3D838A8ADC9385:F153ADFBF163EC6D]:0)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:463)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:763)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
>   at 
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:193)
>   at 
> org.apache.solr.handler.component.TestTwoPhaseDistributedQuery.testNoExtraFieldsRequestedFromShardsInPhaseOne(TestTwoPhaseDistributedQuery.java:79)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>  

[jira] [Commented] (SOLR-14079) SPLITSHARD splitByPrefix doesn't work in async mode

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14079:


Commit 5f8e65c58f5849302d3aaacd65eea46eab258a57 in lucene-solr's branch 
refs/heads/master from Yonik Seeley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5f8e65c ]

SOLR-14079: fix SPLITSHARD splitByPrefix in async mode


> SPLITSHARD splitByPrefix doesn't work in async mode
> ---
>
> Key: SOLR-14079
> URL: https://issues.apache.org/jira/browse/SOLR-14079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-14079.patch
>
>
> If you specify async=whatever in conjunction with splitByPrefix, the ranges 
> are calculated by the shard leader, but that information does not make it 
> back to the overseer and the split proceeds to just split down the middle.



--
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-13884) Concurrent collection creation leads to multiple replicas placed on same node

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-13884:


Commit 73c535261c53d61742516e633edea0036b0f3bf0 in lucene-solr's branch 
refs/heads/master from Yonik Seeley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=73c5352 ]

SOLR-13884: use policies, preferences


> Concurrent collection creation leads to multiple replicas placed on same node
> -
>
> Key: SOLR-13884
> URL: https://issues.apache.org/jira/browse/SOLR-13884
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When multiple collection creations are done concurrently with a 
> collection-level policy, multiple replicas of a single shard can end up on 
> the same node, violating the specified policy.
> This was observed on both 8.2 and master.



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