[jira] [Created] (LUCENE-8511) MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos

[David Smiley (JIRA)]

David Smiley created LUCENE-8511:


 Summary: MultiFields.getIndexedFields can be optimized to not use 
getMergedFieldInfos
 Key: LUCENE-8511
 URL: https://issues.apache.org/jira/browse/LUCENE-8511
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: David Smiley


MultiFields.getIndexedFields calls getMergedFieldInfos.  But 
getMergedFieldInfos is kinda heavy, doing all sorts of stuff that 
getIndexedFields doesn't care about.  It can simply loop the leaf readers and 
collect the results into a Set.  Java 8 streams should make easy work of this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8454) Polygon tessellator can get into an infinite loop

[ASF subversion and git services (JIRA)]

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

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

Commit d494f6be13a585c273c6a3dabc76644f4d480c31 in lucene-solr's branch 
refs/heads/master from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d494f6b ]

LUCENE-8454: Fix incorrect vertex indexing and other computation errors in 
shape tessellation that would sometimes cause an infinite loop.


> Polygon tessellator can get into an infinite loop
> -
>
> Key: LUCENE-8454
> URL: https://issues.apache.org/jira/browse/LUCENE-8454
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8454.patch
>
>
> I was trying to index some shapes using {{LatLonshape}} and for some complex 
> shapes, there teselletor goes into an infinite loop. I am providing a test 
> showing the problem.
>  
> [~nknize], you might be interested on this.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8454) Polygon tessellator can get into an infinite loop

[ASF subversion and git services (JIRA)]

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

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

Commit f54639d4a18bbca98c8853f7e5065a0a3752292c in lucene-solr's branch 
refs/heads/branch_7x from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f54639d ]

LUCENE-8454: Fix incorrect vertex indexing and other computation errors in 
shape tessellation that would sometimes cause an infinite loop.


> Polygon tessellator can get into an infinite loop
> -
>
> Key: LUCENE-8454
> URL: https://issues.apache.org/jira/browse/LUCENE-8454
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8454.patch
>
>
> I was trying to index some shapes using {{LatLonshape}} and for some complex 
> shapes, there teselletor goes into an infinite loop. I am providing a test 
> showing the problem.
>  
> [~nknize], you might be interested on this.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12782) UninvertingReader can be avoided if there are no fields to uninvert

[David Smiley (JIRA)]

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

David Smiley updated SOLR-12782:

Attachment: SOLR-12782.patch

> UninvertingReader can be avoided if there are no fields to uninvert
> ---
>
> Key: SOLR-12782
> URL: https://issues.apache.org/jira/browse/SOLR-12782
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12782.patch, SOLR-12782.patch
>
>
> Solr uses UninvertingReader to expose DocValues on fields that don't have 
> them, but do have indexed fields that can be inverted via the FieldCache. It 
> has an internal constructor that takes the input LeafReader and a mapping of 
> field name to UninvertingReader.Type. It builds a new FieldInfos that have 
> fields reflecting DocValues. There are two things I'd like to improve here:
>  # make this constructor private and instead insist you use a new wrap() 
> method that has the opportunity to return the input if there is nothing to 
> do. Effectively the logic today would move into this wrap method, and the 
> current constructor would be dead simple, and would take the FieldInfos.
>  # Do _not_ create a new {{FieldInfo}} object if the existing field is 
> suitable (it's DocValuesType can stay the same).  The savings here can really 
> add up on machines with many indexes & segments.  This is in fact what 
> motivated the patch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12782) UninvertingReader can be avoided if there are no fields to uninvert

[David Smiley (JIRA)]

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

David Smiley updated SOLR-12782:

Attachment: SOLR-12782.patch

> UninvertingReader can be avoided if there are no fields to uninvert
> ---
>
> Key: SOLR-12782
> URL: https://issues.apache.org/jira/browse/SOLR-12782
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12782.patch, SOLR-12782.patch, SOLR-12782.patch
>
>
> Solr uses UninvertingReader to expose DocValues on fields that don't have 
> them, but do have indexed fields that can be inverted via the FieldCache. It 
> has an internal constructor that takes the input LeafReader and a mapping of 
> field name to UninvertingReader.Type. It builds a new FieldInfos that have 
> fields reflecting DocValues. There are two things I'd like to improve here:
>  # make this constructor private and instead insist you use a new wrap() 
> method that has the opportunity to return the input if there is nothing to 
> do. Effectively the logic today would move into this wrap method, and the 
> current constructor would be dead simple, and would take the FieldInfos.
>  # Do _not_ create a new {{FieldInfo}} object if the existing field is 
> suitable (it's DocValuesType can stay the same).  The savings here can really 
> add up on machines with many indexes & segments.  This is in fact what 
> motivated the patch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on SOLR-5163:
--

Hey, [~Charles Sanders], you could simplify things a bit more. Like [~dsmiley] 
pointed out 
https://jira.apache.org/jira/browse/SOLR-5163?focusedCommentId=16595133=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16595133
 it is more interesting to validate the fields in 
*_DismaxQueryParser#parseQueryFields_* like below:
{code:java}
try {
   for (String e : queryFields.keySet()){
  indexSchema.getField(e);
   }
} catch (SolrException ex) {
  throw new SyntaxError(ex.getMessage());
}

return queryFields;{code}
Or, even use Java8 style like below:
{code:java}
queryFields.keySet().forEach(indexSchema::getField);

return queryFields;{code}
The advantage is double fold: it gets checked for both DismaxParser and 
ExtendedDismaxParser and the logic is in a well defined place (besides being a 
tidy bit more simple).

As for the tests, relying too heavily on String comparisons makes the tests 
fragile (a unrelated change on the return string and the test can fail). IIRC, 
it is even an anti-pattern, but I know it can be difficult not to resort to 
this kind of check then why not make it more economic like below?
{code:java}
/** SOLR-5163 */ 
@Test
public void testValidateQueryFields() throws Exception {

  // test existent qf
  assertJQ(req("defType", "edismax", "df", "text", "q", "olive AND other", 
"qf", "subject^3 title")
  , "/response/numFound==0"
  );

  // test nonexistent qf
  try {
  assertJQ(req("defType", "edismax", "df", "text", "q", "olive AND other", 
"qf", "subject^3 nosuchfield")
  , "/response/numFound==0"
  );
  fail("nosuchfield qf doesn't exists");
  } catch (Exception e) {
 assertEquals("undefined field: \"nosuchfield\"", e.getMessage());
  }{code}
 

Cheers!

> edismax should throw exception when qf refers to nonexistent field
> --
>
> Key: SOLR-5163
> URL: https://issues.apache.org/jira/browse/SOLR-5163
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 4.10.4
>Reporter: Steven Bower
>Assignee: David Smiley
>Priority: Major
>  Labels: newdev
> Attachments: SOLR-5163.patch, SOLR-5163.patch
>
>
> query:
> q=foo AND bar
> qf=field1
> qf=field2
> defType=edismax
> Where field1 exists and field2 doesn't..
> will treat the AND as a term vs and operator



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12782) UninvertingReader can be avoided if there are no fields to uninvert

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12782:
-

The updated patch does what I said in the 2nd paragraph above.  It's a nice 
simplification.  It obsoleted comments and some code pertaining to situations 
where the segments have mixed docValues for a field.  It should "just work".

Tests pass, though I'll want to run again as I made some last-minute changes to 
cleanup.  It'd be nice to get some peer review.  Perhaps [~k317h] would like to 
take a look?  I recall you wrote UninvertDocValuesMergePolicyFactory.

> UninvertingReader can be avoided if there are no fields to uninvert
> ---
>
> Key: SOLR-12782
> URL: https://issues.apache.org/jira/browse/SOLR-12782
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12782.patch, SOLR-12782.patch
>
>
> Solr uses UninvertingReader to expose DocValues on fields that don't have 
> them, but do have indexed fields that can be inverted via the FieldCache. It 
> has an internal constructor that takes the input LeafReader and a mapping of 
> field name to UninvertingReader.Type. It builds a new FieldInfos that have 
> fields reflecting DocValues. There are two things I'd like to improve here:
>  # make this constructor private and instead insist you use a new wrap() 
> method that has the opportunity to return the input if there is nothing to 
> do. Effectively the logic today would move into this wrap method, and the 
> current constructor would be dead simple, and would take the FieldInfos.
>  # Do _not_ create a new {{FieldInfo}} object if the existing field is 
> suitable (it's DocValuesType can stay the same).  The savings here can really 
> add up on machines with many indexes & segments.  This is in fact what 
> motivated the patch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-12785) Add test for activation functions in NeuralNetworkModel

[Kamuela Lau (JIRA)]

Kamuela Lau created SOLR-12785:
--

 Summary: Add test for activation functions in NeuralNetworkModel
 Key: SOLR-12785
 URL: https://issues.apache.org/jira/browse/SOLR-12785
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
  Components: contrib - LTR
Reporter: Kamuela Lau






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (LUCENE-8511) MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos

[David Smiley (JIRA)]

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

David Smiley updated LUCENE-8511:
-
Attachment: LUCENE-8511.patch

> MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos
> 
>
> Key: LUCENE-8511
> URL: https://issues.apache.org/jira/browse/LUCENE-8511
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Minor
> Attachments: LUCENE-8511.patch
>
>
> MultiFields.getIndexedFields calls getMergedFieldInfos.  But 
> getMergedFieldInfos is kinda heavy, doing all sorts of stuff that 
> getIndexedFields doesn't care about.  It can simply loop the leaf readers and 
> collect the results into a Set.  Java 8 streams should make easy work of this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (LUCENE-8511) MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos

[David Smiley (JIRA)]

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

David Smiley reassigned LUCENE-8511:


Assignee: David Smiley

> MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos
> 
>
> Key: LUCENE-8511
> URL: https://issues.apache.org/jira/browse/LUCENE-8511
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: LUCENE-8511.patch
>
>
> MultiFields.getIndexedFields calls getMergedFieldInfos.  But 
> getMergedFieldInfos is kinda heavy, doing all sorts of stuff that 
> getIndexedFields doesn't care about.  It can simply loop the leaf readers and 
> collect the results into a Set.  Java 8 streams should make easy work of this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8454) Polygon tessellator can get into an infinite loop

[ASF subversion and git services (JIRA)]

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

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

Commit e1ceb630bd9d4831a2af6ba30115a27c16f1a4b0 in lucene-solr's branch 
refs/heads/branch_7_5 from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e1ceb63 ]

LUCENE-8454: Fix incorrect vertex indexing and other computation errors in 
shape tessellation that would sometimes cause an infinite loop.


> Polygon tessellator can get into an infinite loop
> -
>
> Key: LUCENE-8454
> URL: https://issues.apache.org/jira/browse/LUCENE-8454
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8454.patch
>
>
> I was trying to index some shapes using {{LatLonshape}} and for some complex 
> shapes, there teselletor goes into an infinite loop. I am providing a test 
> showing the problem.
>  
> [~nknize], you might be interested on this.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 324 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/324/

3 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost

Error Message:
org.apache.solr.common.SolrException: 

Stack Trace:
org.apache.solr.common.SolrException: org.apache.solr.common.SolrException: 
at 
__randomizedtesting.SeedInfo.seed([9EAC1D005CBEB48C:21B9D3FEDF54D10A]:0)
at 
org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:78)
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
at 
org.apache.solr.cloud.autoscaling.ComputePlanActionTest.printState(ComputePlanActionTest.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:993)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.solr.common.SolrException: 
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:300)
at 

[jira] [Resolved] (LUCENE-8454) Polygon tessellator can get into an infinite loop

[Nicholas Knize (JIRA)]

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

Nicholas Knize resolved LUCENE-8454.

Resolution: Fixed

> Polygon tessellator can get into an infinite loop
> -
>
> Key: LUCENE-8454
> URL: https://issues.apache.org/jira/browse/LUCENE-8454
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8454.patch
>
>
> I was trying to index some shapes using {{LatLonshape}} and for some complex 
> shapes, there teselletor goes into an infinite loop. I am providing a test 
> showing the problem.
>  
> [~nknize], you might be interested on this.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12782) UninvertingReader can be avoided if there are no fields to uninvert

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on SOLR-12782:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
36s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m 
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  2m 32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  2m 32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  2m 32s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 88m 59s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 99m 13s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.autoscaling.sim.TestSimTriggerIntegration |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12782 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12940504/SOLR-12782.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-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / d494f6b |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | 1.8.0_172 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/181/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/181/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/181/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> UninvertingReader can be avoided if there are no fields to uninvert
> ---
>
> Key: SOLR-12782
> URL: https://issues.apache.org/jira/browse/SOLR-12782
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12782.patch, SOLR-12782.patch, SOLR-12782.patch
>
>
> Solr uses UninvertingReader to expose DocValues on fields that don't have 
> them, but do have indexed fields that can be inverted via the FieldCache. It 
> has an internal constructor that takes the input LeafReader and a mapping of 
> field name to UninvertingReader.Type. It builds a new FieldInfos that have 
> fields reflecting DocValues. There are two things I'd like to improve here:
>  # make this constructor private and instead insist you use a new wrap() 
> method that has the opportunity to return the input if there is nothing to 
> do. Effectively the logic today would move into this wrap method, and the 
> current constructor would be dead simple, and would take the FieldInfos.
>  # Do _not_ create a new {{FieldInfo}} object if the existing field is 
> suitable (it's DocValuesType can stay the same).  The savings here can really 
> add up on machines with many indexes & segments.  This is in fact what 
> motivated the patch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (LUCENE-7875) Rename or move most of MultiFields

[David Smiley (JIRA)]

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

David Smiley reassigned LUCENE-7875:


Assignee: David Smiley

> Rename or move most of MultiFields
> --
>
> Key: LUCENE-7875
> URL: https://issues.apache.org/jira/browse/LUCENE-7875
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
>
> MultiFields.java has a bunch of static methods that provide a single 
> LeafReader's view over a bunch of things.
> These could perhaps go to ReaderUtil:
> * {{Bits getLiveDocs(IndexReader reader)}}
> * {{FieldInfos getMergedFieldInfos(IndexReader reader)}} (removing "Merged" 
> in its name which seems inconsistent, or replace with "Multi")
> These could perhaps go to MultiTerms:
> * {{Collection getIndexedFields(IndexReader reader)}}
> * {{Terms getTerms(IndexReader r, String field)}}
> * {{PostingsEnum getTermDocsEnum(IndexReader r, String field, BytesRef term)}}
> Finally, the MultiFields instance itself, implementing {{Fields}} along with 
> the static utility method {{Fields getFields(IndexReader reader)}} could 
> perhaps remain until we can finally remove it (or move to a test classpath or 
> something) when there is no more purpose for Fields.java.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-7875) Rename or move most of MultiFields

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7875:
--

It's a shame MultiReader is already taken as a name since it'd be a good place 
for some of these methods given our use of Multi in many places.  Perhaps 
MultiLeafReader could be a new class to hold these utilities?

I'd like to get these changes into 8.0, to further ween ourselves off of 
MultiFields.

> Rename or move most of MultiFields
> --
>
> Key: LUCENE-7875
> URL: https://issues.apache.org/jira/browse/LUCENE-7875
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
>
> MultiFields.java has a bunch of static methods that provide a single 
> LeafReader's view over a bunch of things.
> These could perhaps go to ReaderUtil:
> * {{Bits getLiveDocs(IndexReader reader)}}
> * {{FieldInfos getMergedFieldInfos(IndexReader reader)}} (removing "Merged" 
> in its name which seems inconsistent, or replace with "Multi")
> These could perhaps go to MultiTerms:
> * {{Collection getIndexedFields(IndexReader reader)}}
> * {{Terms getTerms(IndexReader r, String field)}}
> * {{PostingsEnum getTermDocsEnum(IndexReader r, String field, BytesRef term)}}
> Finally, the MultiFields instance itself, implementing {{Fields}} along with 
> the static utility method {{Fields getFields(IndexReader reader)}} could 
> perhaps remain until we can finally remove it (or move to a test classpath or 
> something) when there is no more purpose for Fields.java.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [VOTE] Release Lucene/Solr 7.5.0 RC1

[Jan Høydahl]

+1

SUCCESS! [1:43:42.160258]

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 18. sep. 2018 kl. 18:09 skrev jim ferenczi :
> 
> Please vote for release candidate 1 for Lucene/Solr 7.5.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
>  
> 
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
>  
> 
> 
> Here's my +1
> SUCCESS! [1:33:42.884535]

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-10.0.1) - Build # 22888 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22888/
Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 14752 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/temp/junit4-J1-20180919_225421_77012120554645036652309.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0x7f5af0634409, pid=16321, tid=16351
   [junit4] #
   [junit4] # JRE version: OpenJDK Runtime Environment (10.0.1+10) (build 
10.0.1+10)
   [junit4] # Java VM: OpenJDK 64-Bit Server VM (10.0.1+10, mixed mode, tiered, 
serial gc, linux-amd64)
   [junit4] # Problematic frame:
   [junit4] # V  [libjvm.so+0xc48409]  PhaseIdealLoop::split_up(Node*, Node*, 
Node*) [clone .part.40]+0x619
   [junit4] #
   [junit4] # No core dump will be written. Core dumps have been disabled. To 
enable core dumping, try "ulimit -c unlimited" before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/hs_err_pid16321.log
   [junit4] #
   [junit4] # Compiler replay data is saved as:
   [junit4] # 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/replay_pid16321.log
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.java.com/bugreport/crash.jsp
   [junit4] #
   [junit4] <<< JVM J1: EOF 

[...truncated 642 lines...]
   [junit4] ERROR: JVM J1 ended with an exception, command line: 
/home/jenkins/tools/java/64bit/jdk-10.0.1/bin/java -XX:-UseCompressedOops 
-XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-master-Linux/heapdumps -ea 
-esa --illegal-access=deny -Dtests.prefix=tests -Dtests.seed=2ECF55828BC46C78 
-Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false 
-Dtests.codec=random -Dtests.postingsformat=random 
-Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
-Dtests.luceneMatchVersion=8.0.0 -Dtests.cleanthreads=perClass 
-Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene 
-Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/clover/db
 
-Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/junit4/solr-tests.policy
 -Dtests.LUCENE_VERSION=8.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.src.home=/home/jenkins/workspace/Lucene-Solr-master-Linux 
-Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1
 
-Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/temp
 -Djunit4.childvm.id=1 -Djunit4.childvm.count=3 -Dfile.encoding=ISO-8859-1 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dtests.filterstacks=true -Dtests.leaveTemporary=false -Dtests.badapples=false 
-classpath 

[jira] [Commented] (LUCENE-8509) NGramTokenizer, TrimFilter and WordDelimiterGraphFilter in combination can produce backwards offsets

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-8509:
---

I don't think this is fixable with the current setup, but it's another argument 
for making WordDelimiterGraphFilter a tokenizer.

> NGramTokenizer, TrimFilter and WordDelimiterGraphFilter in combination can 
> produce backwards offsets
> 
>
> Key: LUCENE-8509
> URL: https://issues.apache.org/jira/browse/LUCENE-8509
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
>
> Discovered by an elasticsearch user and described here: 
> https://github.com/elastic/elasticsearch/issues/33710
> The ngram tokenizer produces tokens "a b" and " bb" (note the space at the 
> beginning of the second token).  The WDGF takes the first token and splits it 
> into two, adjusting the offsets of the second token, so we get "a"[0,1] and 
> "b"[2,3].  The trim filter removes the leading space from the second token, 
> leaving offsets unchanged, so WDGF sees "bb"[1,4]; because the leading space 
> has already been stripped, WDGF sees no need to adjust offsets, and emits the 
> token as-is, resulting in the start offsets of the tokenstream being [0, 2, 
> 1], and the IndexWriter rejecting it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (LUCENE-1360) A Similarity class which has unique length norms for numTerms <= 10

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-1360.
--
Resolution: Fixed

Lengths are recorded accurately up to a length of 40 since 7.0 thanks to 
LUCENE-7730.

> A Similarity class which has unique length norms for numTerms <= 10
> ---
>
> Key: LUCENE-1360
> URL: https://issues.apache.org/jira/browse/LUCENE-1360
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/query/scoring
>Reporter: Sean Timm
>Assignee: Otis Gospodnetic
>Priority: Trivial
> Attachments: LUCENE-1360.patch, LUCENE-1380 visualization.pdf, 
> ShortFieldNormSimilarity.java
>
>
> A Similarity class which extends DefaultSimilarity and simply overrides 
> lengthNorm.  lengthNorm is implemented as a lookup for numTerms <= 10, else 
> as {{1/sqrt(numTerms)}}. This is to avoid term counts below 11 from having 
> the same lengthNorm after stored as a single byte in the index.
> This is useful if your search is only on short fields such as titles or 
> product descriptions.
> See mailing list discussion: 
> http://www.nabble.com/How-to-boost-the-score-higher-in-case-user-query-matches-entire-field-value-than-just-some-words-within-a-field-td19079221.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (LUCENE-3957) Document precision requirements of setBoost calls

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-3957.
--
Resolution: Invalid

We don't support index-time boosts anymore.

> Document precision requirements of setBoost calls
> -
>
> Key: LUCENE-3957
> URL: https://issues.apache.org/jira/browse/LUCENE-3957
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/javadocs
>Affects Versions: 3.5
>Reporter: Jordi Salvat i Alabart
>Priority: Major
>
> The behaviour of index-time boosts seems pretty erratic (e.g. a boost of 8.0 
> produces the exact same score as a boost of 9.0) until you become aware that 
> these factors end up encoded in a single byte, with a three-bit mantissa. 
> This consumed a whole day of research for us, and I still believe we were 
> lucky to spot it, given how deeply dug into the code & documentation this 
> information is.
> I suggest adding a small note to the JavaDoc of setBoost methods in Document, 
> Fieldable, FieldInvertState, and possibly AbstractField, Field, and 
> NumericField.
> Suggested text:
> "Note that all index-time boost values end up encoded using 
> Similarity.encodeNormValue, with a 3-bit mantissa -- so differences in the 
> boost value of less than 25% may easily be rounded away."



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8498) Deprecate/Remove LowerCaseTokenizer

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-8498:
---

Precommit has caught an interesting wrinkle here, in that CharTokenizer also 
allows you to combine tokenization and normalization.  As currently written, a 
CharTokenizer combined with a normalizer will not have its normalization 
applied when Analyzer.normalize() is called.  Should we also remove the 
normalization functions from CharTokenizer?  cc [~thetaphi]

> Deprecate/Remove LowerCaseTokenizer
> ---
>
> Key: LUCENE-8498
> URL: https://issues.apache.org/jira/browse/LUCENE-8498
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8498.patch
>
>
> LowerCaseTokenizer combines tokenization and filtering in a way that prevents 
> us improving the normalization API.  We should deprecate and remove it, as it 
> can be replaced simply with a LetterTokenizer and LowerCaseFilter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (LUCENE-8421) TopScoreDocCollector.create(int) should disable exact hit counts

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-8421.
--
Resolution: Won't Fix

We ended up addressing this need differently. TopScoreDocCollector now always 
takes a totalHitsThreshold.

> TopScoreDocCollector.create(int) should disable exact hit counts
> 
>
> Key: LUCENE-8421
> URL: https://issues.apache.org/jira/browse/LUCENE-8421
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8421.patch
>
>
> We should make TopScoreDocCollector.create(int) disable exact hit counts so 
> that users don't have to opt out to get faster queries. Users can still get 
> exact counts by using the other factory method 
> TopScoreDocCollector.create(int,ScoreDoc,boolean).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8484) Drop fully deleted reader in SubReaderWrapper

[ASF subversion and git services (JIRA)]

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

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

Commit 5981895cb48416f1133702a35bf9811f963f3ed9 in lucene-solr's branch 
refs/heads/master from [~dnhatn]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5981895 ]

LUCENE-8484: Account dropped sub-readers in test


> Drop fully deleted reader in SubReaderWrapper
> -
>
> Key: LUCENE-8484
> URL: https://issues.apache.org/jira/browse/LUCENE-8484
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Minor
> Fix For: 7.5, master (8.0)
>
> Attachments: LUCENE-8484.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Today we can only wrap readers in SubReaderWrapper but never filter them out
> entirely. This causes a invariant for soft-deletes that exposes fully deleted
> segments with SoftDeletesDirectoryReaderWrapper. This change drops fully 
> deleted readers after they are wrapped.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries

[Randy Fradin (JIRA)]

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

Randy Fradin commented on SOLR-6930:


I would love to see this feature get implemented. Understandable that it would 
be disabled by default, but I'm operating exactly the type of large SolrCloud 
cluster with many clients that [~markrmil...@gmail.com] describes and having a 
circuit breaker would help everyone sleep better at night knowing one mistaken 
query can't take out a node by causing too much memory allocation.

I would think there should be a configurable "soft limit" and "hard limit" so 
you get a WARN in the logs if the soft limit is breached and the query is 
failed preemptively only if the hard limit is reached. That way if the memory 
cost of a query is creeping up due to growth in the data set, you can get an 
early warning that things are headed in a bad direction before queries start 
failing. In fact the INFO line that's logged with every query completion could 
include estimated memory required to complete the query.

Of course this sounds complex to implement and I'm not at all a Solr expert so 
I don't really know where to begin - any of the experts know in broad strokes 
what the memory estimation equation would look like ?

 

> Provide "Circuit Breakers" For Expensive Solr Queries
> -
>
> Key: SOLR-6930
> URL: https://issues.apache.org/jira/browse/SOLR-6930
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Mike Drob
>Priority: Major
>
> Ref: 
> http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html
> ES currently allows operators to configure "circuit breakers" to preemptively 
> fail queries that are estimated too large rather than allowing an OOM 
> Exception to happen. We might be able to do the same thing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8498) Deprecate/Remove LowerCaseTokenizer

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8498:
-

+1. I think it was added mainly to support LowerCaseTokenizer so it only makes 
sense to clean it up (and let CharTokenizer just do tokenizaiton).

> Deprecate/Remove LowerCaseTokenizer
> ---
>
> Key: LUCENE-8498
> URL: https://issues.apache.org/jira/browse/LUCENE-8498
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8498.patch
>
>
> LowerCaseTokenizer combines tokenization and filtering in a way that prevents 
> us improving the normalization API.  We should deprecate and remove it, as it 
> can be replaced simply with a LetterTokenizer and LowerCaseFilter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8498) Deprecate/Remove LowerCaseTokenizer

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-8498:
---

Sorry, the issue is about LowercaseTokenizer :-) So +1 to rmeove the tokenizer 
and removal of chartokenizer's normalization methods.

> Deprecate/Remove LowerCaseTokenizer
> ---
>
> Key: LUCENE-8498
> URL: https://issues.apache.org/jira/browse/LUCENE-8498
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8498.patch
>
>
> LowerCaseTokenizer combines tokenization and filtering in a way that prevents 
> us improving the normalization API.  We should deprecate and remove it, as it 
> can be replaced simply with a LetterTokenizer and LowerCaseFilter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

***UNCHECKED*** [jira] [Commented] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-6930:
--

You do already have a kind of "warn" here, you can configure the "slow query 
logging". It's not quite what you're looking for, but may be useful in the 
interim.

> Provide "Circuit Breakers" For Expensive Solr Queries
> -
>
> Key: SOLR-6930
> URL: https://issues.apache.org/jira/browse/SOLR-6930
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Mike Drob
>Priority: Major
>
> Ref: 
> http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html
> ES currently allows operators to configure "circuit breakers" to preemptively 
> fail queries that are estimated too large rather than allowing an OOM 
> Exception to happen. We might be able to do the same thing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8506) TestAddIndexes.testAddIndicesWithSoftDeletes() failures

[Nhat Nguyen (JIRA)]

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

Nhat Nguyen commented on LUCENE-8506:
-

Thanks [~steve_rowe] for linking these issues.

> TestAddIndexes.testAddIndicesWithSoftDeletes() failures
> ---
>
> Key: LUCENE-8506
> URL: https://issues.apache.org/jira/browse/LUCENE-8506
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index, general/test
>Reporter: Steve Rowe
>Priority: Major
>
> {{TestAddIndexes.testAddIndicesWithSoftDeletes()}} has failed a few times on 
> Jenkins (see below), but the seeds don't reproduce 100%: of the two I tested, 
> one didn't reproduce at all in 5 iterations, and the other reproduced 1/5 
> iterations.
> I beasted the suite on master 50 times using Miller's beasting script and it 
> failed just once:
> {noformat}
> ({{git show}} reports: {{commit 895bff46b2c3d3d027e693e11a2feac9f518191d}})
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestAddIndexes 
> -Dtests.method=testAddIndicesWithSoftDeletes -Dtests.seed=70F06A77576A75 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-YE 
> -Dtests.timezone=Iceland -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.40s | TestAddIndexes.testAddIndicesWithSoftDeletes <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 1, 
> Size: 1
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([70F06A77576A75:2C240F2EC2524E6D]:0)
>[junit4]>at java.util.ArrayList.rangeCheck(ArrayList.java:657)
>[junit4]>at java.util.ArrayList.get(ArrayList.java:433)
>[junit4]>at 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)
>[junit4]>at 
> org.apache.lucene.index.TestAddIndexes.testAddIndicesWithSoftDeletes(TestAddIndexes.java:1452)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene80): 
> {c=BlockTreeOrds(blocksize=128), id=BlockTreeOrds(blocksize=128), 
> f1=BlockTreeOrds(blocksize=128), f2=Lucene50(blocksize=128), 
> version=Lucene50(blocksize=128), content=FSTOrd50}, 
> docValues:{dv=DocValuesFormat(name=Asserting), 
> soft_delete=DocValuesFormat(name=Lucene70), 
> doc=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Direct), 
> content=DocValuesFormat(name=Lucene70), 
> doc2d=DocValuesFormat(name=Asserting)}, maxPointsInLeafNode=69, 
> maxMBSortInHeap=5.930450658985216, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@35111f6),
>  locale=ar-YE, timezone=Iceland
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_171 (64-bit)/cpus=16,threads=1,free=490798376,total=511180800
> {noformat}
> Jenkins failures (all on branch_7x):
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/814/]:
> {noformat}
> Checking out Revision 0789a77c2590f716fc3cedb247309068c3fc5d85 
> (refs/remotes/origin/branch_7x)
> [...]
>   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestAddIndexes 
> -Dtests.method=testAddIndicesWithSoftDeletes -Dtests.seed=B80C15673B91141 
> -Dtests.slow=true -Dtests.locale=es-SV -Dtests.timezone=Asia/Jakarta 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>   [junit4] ERROR   0.02s J0 | TestAddIndexes.testAddIndicesWithSoftDeletes <<<
>   [junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 2, 
> Size: 2
>   [junit4]>   at 
> __randomizedtesting.SeedInfo.seed([B80C15673B91141:27D43E12C6BC3559]:0)
>   [junit4]>   at java.util.ArrayList.rangeCheck(ArrayList.java:657)
>   [junit4]>   at java.util.ArrayList.get(ArrayList.java:433)
>   [junit4]>   at 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)
>   [junit4]>   at 
> org.apache.lucene.index.TestAddIndexes.testAddIndicesWithSoftDeletes(TestAddIndexes.java:1455)
>   [junit4]>   at java.lang.Thread.run(Thread.java:748)
> [...]
>   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {c=PostingsFormat(name=LuceneVarGapDocFreqInterval), 
> id=PostingsFormat(name=LuceneVarGapDocFreqInterval), 
> f1=PostingsFormat(name=LuceneVarGapDocFreqInterval), f2=FSTOrd50, 
> version=FSTOrd50, content=BlockTreeOrds(blocksize=128)}, 
> docValues:{dv=DocValuesFormat(name=Direct), 
> soft_delete=DocValuesFormat(name=Asserting), 
> doc=DocValuesFormat(name=Asserting), id=DocValuesFormat(name=Lucene70), 
> content=DocValuesFormat(name=Memory), doc2d=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=584, maxMBSortInHeap=7.761726159162388, 
> sim=RandomSimilarity(queryNorm=true): {foo=DFR I(ne)BZ(0.3), id=DFR GL2, 
> content=IB SPL-L1}, locale=es-SV, timezone=Asia/Jakarta
>   [junit4]   

[jira] [Created] (LUCENE-8509) NGramTokenizer, TrimFilter and WordDelimiterGraphFilter in combination can produce backwards offsets

[Alan Woodward (JIRA)]

Alan Woodward created LUCENE-8509:
-

 Summary: NGramTokenizer, TrimFilter and WordDelimiterGraphFilter 
in combination can produce backwards offsets
 Key: LUCENE-8509
 URL: https://issues.apache.org/jira/browse/LUCENE-8509
 Project: Lucene - Core
  Issue Type: Task
Reporter: Alan Woodward
Assignee: Alan Woodward


Discovered by an elasticsearch user and described here: 
https://github.com/elastic/elasticsearch/issues/33710

The ngram tokenizer produces tokens "a b" and " bb" (note the space at the 
beginning of the second token).  The WDGF takes the first token and splits it 
into two, adjusting the offsets of the second token, so we get "a"[0,1] and 
"b"[2,3].  The trim filter removes the leading space from the second token, 
leaving offsets unchanged, so WDGF sees "bb"[1,4]; because the leading space 
has already been stripped, WDGF sees no need to adjust offsets, and emits the 
token as-is, resulting in the start offsets of the tokenstream being [0, 2, 1], 
and the IndexWriter rejecting it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (LUCENE-5499) EarlyTerminatingSortingCollector shouldnt require exact Sort match

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-5499.
--
Resolution: Fixed

I can't find exactly when, but this has been fixed: TopFieldCollector now 
early-terminates if the search sort is a prefix of the index sort.

> EarlyTerminatingSortingCollector shouldnt require exact Sort match
> --
>
> Key: LUCENE-5499
> URL: https://issues.apache.org/jira/browse/LUCENE-5499
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
>
> Today EarlyTerminatingSortingCollector requires that the Sort match exactly 
> at query and at index time.
> However, now that you can use any Sort (e.g. with multiple sortfields), this 
> should be improved.
> For example, early termination is fine in the following case:
> * index-time: popularity desc, time desc
> * query-time: popularity desc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (LUCENE-8484) Drop fully deleted reader in SubReaderWrapper

[Nhat Nguyen (JIRA)]

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

Nhat Nguyen resolved LUCENE-8484.
-
Resolution: Fixed

> Drop fully deleted reader in SubReaderWrapper
> -
>
> Key: LUCENE-8484
> URL: https://issues.apache.org/jira/browse/LUCENE-8484
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Minor
> Fix For: 7.5, master (8.0)
>
> Attachments: LUCENE-8484.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Today we can only wrap readers in SubReaderWrapper but never filter them out
> entirely. This causes a invariant for soft-deletes that exposes fully deleted
> segments with SoftDeletesDirectoryReaderWrapper. This change drops fully 
> deleted readers after they are wrapped.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8484) Drop fully deleted reader in SubReaderWrapper

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-8484:


Looks like the latest commit will fix the failures reported in LUCENE-8506 .

> Drop fully deleted reader in SubReaderWrapper
> -
>
> Key: LUCENE-8484
> URL: https://issues.apache.org/jira/browse/LUCENE-8484
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Minor
> Fix For: 7.5, master (8.0)
>
> Attachments: LUCENE-8484.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Today we can only wrap readers in SubReaderWrapper but never filter them out
> entirely. This causes a invariant for soft-deletes that exposes fully deleted
> segments with SoftDeletesDirectoryReaderWrapper. This change drops fully 
> deleted readers after they are wrapped.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8498) Deprecate/Remove LowerCaseTokenizer

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-8498:
---

+1, I think we should remove that. If we do that, we also have to remove 
LowercaseTokenizer (that is LetterTokenizer / Whitespace with Lowercasing).

> Deprecate/Remove LowerCaseTokenizer
> ---
>
> Key: LUCENE-8498
> URL: https://issues.apache.org/jira/browse/LUCENE-8498
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8498.patch
>
>
> LowerCaseTokenizer combines tokenization and filtering in a way that prevents 
> us improving the normalization API.  We should deprecate and remove it, as it 
> can be replaced simply with a LetterTokenizer and LowerCaseFilter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

***UNCHECKED*** [jira] [Updated] (SOLR-12784) SOLR Documentation "Link Not Found"

[Cassandra Targett (JIRA)]

[jira] [Resolved] (LUCENE-8501) An ability to define the sum method for custom term frequencies

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-8501.
--
Resolution: Won't Fix

bq. If that change is not in the line of the project, I guess we can just close 
this issue and live with workarounds.

This might change in the future, but as things stand today, I think this is 
something that we wouldn't like to change.

> An ability to define the sum method for custom term frequencies
> ---
>
> Key: LUCENE-8501
> URL: https://issues.apache.org/jira/browse/LUCENE-8501
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Olli Kuonanoja
>Priority: Major
>
> Custom term frequencies allows expert users to index and score in custom 
> ways, however, _DefaultIndexingChain_ adds a limitation to this as the sum of 
> frequencies can't overflow
> {code:java}
> try {
> invertState.length = Math.addExact(invertState.length, 
> invertState.termFreqAttribute.getTermFrequency());
> } catch (ArithmeticException ae) {
> throw new IllegalArgumentException("too many tokens for field \"" + 
> field.name() + "\"");
> }
> {code}
> This might become an issue if for example the frequency data is encoded in a 
> different way, say the specific scorer works with float frequencies.
> The sum method can be added to _TermFrequencyAttribute_ to get something like
> {code:java}
> invertState.length = 
> invertState.termFreqAttribute.addFrequency(invertState.length);
> {code}
> so users may define the summing method and avoid the owerflow exceptions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8484) Drop fully deleted reader in SubReaderWrapper

[ASF subversion and git services (JIRA)]

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

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

Commit c5ee4bcd2bbe73ba8655b8ef3a6c45e872234ab2 in lucene-solr's branch 
refs/heads/branch_7x from [~dnhatn]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c5ee4bc ]

LUCENE-8484: Account dropped sub-readers in test


> Drop fully deleted reader in SubReaderWrapper
> -
>
> Key: LUCENE-8484
> URL: https://issues.apache.org/jira/browse/LUCENE-8484
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Minor
> Fix For: 7.5, master (8.0)
>
> Attachments: LUCENE-8484.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Today we can only wrap readers in SubReaderWrapper but never filter them out
> entirely. This causes a invariant for soft-deletes that exposes fully deleted
> segments with SoftDeletesDirectoryReaderWrapper. This change drops fully 
> deleted readers after they are wrapped.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

***UNCHECKED*** [jira] [Commented] (LUCENE-8484) Drop fully deleted reader in SubReaderWrapper

[ASF subversion and git services (JIRA)]

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

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

Commit 96221291b5b9cf55907759ba905bc1f4479f3437 in lucene-solr's branch 
refs/heads/branch_7_5 from [~dnhatn]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9622129 ]

LUCENE-8484: Account dropped sub-readers in test


> Drop fully deleted reader in SubReaderWrapper
> -
>
> Key: LUCENE-8484
> URL: https://issues.apache.org/jira/browse/LUCENE-8484
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Minor
> Fix For: 7.5, master (8.0)
>
> Attachments: LUCENE-8484.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Today we can only wrap readers in SubReaderWrapper but never filter them out
> entirely. This causes a invariant for soft-deletes that exposes fully deleted
> segments with SoftDeletesDirectoryReaderWrapper. This change drops fully 
> deleted readers after they are wrapped.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (LUCENE-8506) TestAddIndexes.testAddIndicesWithSoftDeletes() failures

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-8506.

Resolution: Fixed

Fixed by a commit on LUCENE-8484.

> TestAddIndexes.testAddIndicesWithSoftDeletes() failures
> ---
>
> Key: LUCENE-8506
> URL: https://issues.apache.org/jira/browse/LUCENE-8506
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index, general/test
>Reporter: Steve Rowe
>Priority: Major
>
> {{TestAddIndexes.testAddIndicesWithSoftDeletes()}} has failed a few times on 
> Jenkins (see below), but the seeds don't reproduce 100%: of the two I tested, 
> one didn't reproduce at all in 5 iterations, and the other reproduced 1/5 
> iterations.
> I beasted the suite on master 50 times using Miller's beasting script and it 
> failed just once:
> {noformat}
> ({{git show}} reports: {{commit 895bff46b2c3d3d027e693e11a2feac9f518191d}})
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestAddIndexes 
> -Dtests.method=testAddIndicesWithSoftDeletes -Dtests.seed=70F06A77576A75 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-YE 
> -Dtests.timezone=Iceland -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.40s | TestAddIndexes.testAddIndicesWithSoftDeletes <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 1, 
> Size: 1
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([70F06A77576A75:2C240F2EC2524E6D]:0)
>[junit4]>at java.util.ArrayList.rangeCheck(ArrayList.java:657)
>[junit4]>at java.util.ArrayList.get(ArrayList.java:433)
>[junit4]>at 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)
>[junit4]>at 
> org.apache.lucene.index.TestAddIndexes.testAddIndicesWithSoftDeletes(TestAddIndexes.java:1452)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene80): 
> {c=BlockTreeOrds(blocksize=128), id=BlockTreeOrds(blocksize=128), 
> f1=BlockTreeOrds(blocksize=128), f2=Lucene50(blocksize=128), 
> version=Lucene50(blocksize=128), content=FSTOrd50}, 
> docValues:{dv=DocValuesFormat(name=Asserting), 
> soft_delete=DocValuesFormat(name=Lucene70), 
> doc=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Direct), 
> content=DocValuesFormat(name=Lucene70), 
> doc2d=DocValuesFormat(name=Asserting)}, maxPointsInLeafNode=69, 
> maxMBSortInHeap=5.930450658985216, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@35111f6),
>  locale=ar-YE, timezone=Iceland
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_171 (64-bit)/cpus=16,threads=1,free=490798376,total=511180800
> {noformat}
> Jenkins failures (all on branch_7x):
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/814/]:
> {noformat}
> Checking out Revision 0789a77c2590f716fc3cedb247309068c3fc5d85 
> (refs/remotes/origin/branch_7x)
> [...]
>   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestAddIndexes 
> -Dtests.method=testAddIndicesWithSoftDeletes -Dtests.seed=B80C15673B91141 
> -Dtests.slow=true -Dtests.locale=es-SV -Dtests.timezone=Asia/Jakarta 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>   [junit4] ERROR   0.02s J0 | TestAddIndexes.testAddIndicesWithSoftDeletes <<<
>   [junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 2, 
> Size: 2
>   [junit4]>   at 
> __randomizedtesting.SeedInfo.seed([B80C15673B91141:27D43E12C6BC3559]:0)
>   [junit4]>   at java.util.ArrayList.rangeCheck(ArrayList.java:657)
>   [junit4]>   at java.util.ArrayList.get(ArrayList.java:433)
>   [junit4]>   at 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)
>   [junit4]>   at 
> org.apache.lucene.index.TestAddIndexes.testAddIndicesWithSoftDeletes(TestAddIndexes.java:1455)
>   [junit4]>   at java.lang.Thread.run(Thread.java:748)
> [...]
>   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {c=PostingsFormat(name=LuceneVarGapDocFreqInterval), 
> id=PostingsFormat(name=LuceneVarGapDocFreqInterval), 
> f1=PostingsFormat(name=LuceneVarGapDocFreqInterval), f2=FSTOrd50, 
> version=FSTOrd50, content=BlockTreeOrds(blocksize=128)}, 
> docValues:{dv=DocValuesFormat(name=Direct), 
> soft_delete=DocValuesFormat(name=Asserting), 
> doc=DocValuesFormat(name=Asserting), id=DocValuesFormat(name=Lucene70), 
> content=DocValuesFormat(name=Memory), doc2d=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=584, maxMBSortInHeap=7.761726159162388, 
> sim=RandomSimilarity(queryNorm=true): {foo=DFR I(ne)BZ(0.3), id=DFR GL2, 
> content=IB SPL-L1}, locale=es-SV, timezone=Asia/Jakarta
>   [junit4]   2> NOTE: SunOS 5.11 

***UNCHECKED*** [jira] [Comment Edited] (LUCENE-8498) Deprecate/Remove LowerCaseTokenizer

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-8498 at 9/19/18 2:38 PM:


Sorry, the issue is about LowercaseTokenizer :-) So +1 to rmeove the tokenizer 
and removal of chartokenizer's normalization methods (the abstract method and 
the factory methods using java.util.function).


was (Author: thetaphi):
Sorry, the issue is about LowercaseTokenizer :-) So +1 to rmeove the tokenizer 
and removal of chartokenizer's normalization methods.

> Deprecate/Remove LowerCaseTokenizer
> ---
>
> Key: LUCENE-8498
> URL: https://issues.apache.org/jira/browse/LUCENE-8498
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8498.patch
>
>
> LowerCaseTokenizer combines tokenization and filtering in a way that prevents 
> us improving the normalization API.  We should deprecate and remove it, as it 
> can be replaced simply with a LetterTokenizer and LowerCaseFilter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8484) Drop fully deleted reader in SubReaderWrapper

[Nhat Nguyen (JIRA)]

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

Nhat Nguyen commented on LUCENE-8484:
-

[~steve_rowe] Yes.

> Drop fully deleted reader in SubReaderWrapper
> -
>
> Key: LUCENE-8484
> URL: https://issues.apache.org/jira/browse/LUCENE-8484
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Minor
> Fix For: 7.5, master (8.0)
>
> Attachments: LUCENE-8484.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Today we can only wrap readers in SubReaderWrapper but never filter them out
> entirely. This causes a invariant for soft-deletes that exposes fully deleted
> segments with SoftDeletesDirectoryReaderWrapper. This change drops fully 
> deleted readers after they are wrapped.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SOLR-12784) SOLR Documentation "Link Not Found"

[Cassandra Targett (JIRA)]

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

Cassandra Targett reassigned SOLR-12784:


Assignee: Cassandra Targett

> SOLR Documentation "Link Not Found"
> ---
>
> Key: SOLR-12784
> URL: https://issues.apache.org/jira/browse/SOLR-12784
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.4
>Reporter: Stephen Lewis Bianamara
>Assignee: Cassandra Targett
>Priority: Major
>  Labels: Documentation
>
> This page has a broken link for at least two SOLR versions I checked (7.4 and 
> 6.6)
> https://lucene.apache.org/solr/guide/7_4/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory
>  
> [https://lucene.apache.org/solr/guide/6_6/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory]
> The broken link is an example to stemdict.txt and reports
> """
> The requested URL 
> /repos/asf/lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/stemdict.txt
>  was not found on this server.
> """



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

***UNCHECKED*** [jira] [Commented] (SOLR-12784) SOLR Documentation "Link Not Found"

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-12784:
--

gahh, I feel like someone else mentioned this recently and I thought I fixed it.

The reason the link is broken is that it points to the old Subversion repo. We 
moved everything to Git a couple years ago and this link never got fixed 
apparently. The correct link today is 
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=blob;f=solr/core/src/test-files/solr/collection1/conf/stemdict.txt.

Instead of pointing to the file like we do today, I'll see if I can do 
something better like dynamically pull it from the repo into the page itself 
when we build the page.

> SOLR Documentation "Link Not Found"
> ---
>
> Key: SOLR-12784
> URL: https://issues.apache.org/jira/browse/SOLR-12784
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Stephen Lewis Bianamara
>Priority: Major
>  Labels: Documentation
>
> This page has a broken link for at least two SOLR versions I checked (7.4 and 
> 6.6)
> https://lucene.apache.org/solr/guide/7_4/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory
>  
> [https://lucene.apache.org/solr/guide/6_6/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory]
> The broken link is an example to stemdict.txt and reports
> """
> The requested URL 
> /repos/asf/lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/stemdict.txt
>  was not found on this server.
> """



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12784) SOLR Documentation "Link Not Found"

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12784:
-
Affects Version/s: 7.4

> SOLR Documentation "Link Not Found"
> ---
>
> Key: SOLR-12784
> URL: https://issues.apache.org/jira/browse/SOLR-12784
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.4
>Reporter: Stephen Lewis Bianamara
>Priority: Major
>  Labels: Documentation
>
> This page has a broken link for at least two SOLR versions I checked (7.4 and 
> 6.6)
> https://lucene.apache.org/solr/guide/7_4/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory
>  
> [https://lucene.apache.org/solr/guide/6_6/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory]
> The broken link is an example to stemdict.txt and reports
> """
> The requested URL 
> /repos/asf/lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/stemdict.txt
>  was not found on this server.
> """



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8498) Deprecate/Remove LowerCaseTokenizer

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8498:
--

+1 to remove normalization from CharTokenizer too.

> Deprecate/Remove LowerCaseTokenizer
> ---
>
> Key: LUCENE-8498
> URL: https://issues.apache.org/jira/browse/LUCENE-8498
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8498.patch
>
>
> LowerCaseTokenizer combines tokenization and filtering in a way that prevents 
> us improving the normalization API.  We should deprecate and remove it, as it 
> can be replaced simply with a LetterTokenizer and LowerCaseFilter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

***UNCHECKED*** [jira] [Created] (LUCENE-8510) Better maximum scores for boolean queries

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-8510:


 Summary: Better maximum scores for boolean queries
 Key: LUCENE-8510
 URL: https://issues.apache.org/jira/browse/LUCENE-8510
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand


The maximum score of boolean queries is the sum of the maximum score of each 
clause. In the common case that each sub query runs on the same field, we might 
be able to get better estimates though. Say the query looks like "body:A 
body:B": if the maximum score of "body:A" is obtained for a document of length 
X and the maximum score of "body:B" is obtained for a document of length Y!=X 
then the sum of these maximum scores may never be reached: since both clauses 
have to match the same document, the maximum scores of each clause should be 
computed for the same value of the norm.

Improving our APIs to improve this sounds challenging, but I was wondering that 
we could obtain almost the same result by enabling to sort by norm value, so 
that we would combine maximum scores of clauses that have the same norm.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries

[Randy Fradin (JIRA)]

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

Randy Fradin commented on SOLR-6930:


Thanks [~erickerickson] we do use that and it is useful, but time spent 
processing a query is only a rough proxy for the memory expense of a query, 
plus of course we're missing the blocking feature (which timeAllowed sort of 
gives you on the time dimension, except that it's opt-in from the client not 
enforceable on all queries by the server, and can't be used with cursorMark, 
and can't be relied on to kill a query when the time expires regardless of 
where it is in its execution process).

We have problems both with poorly thought out queries leading to OOM and with 
queries that don't quite lead to an OOM but do cause memory allocation to 
happen fast enough that the garbage collector can't keep up, leading to full GC 
pauses for up to 10s of seconds, sometimes long enough to cause the ZooKeeper 
session to expire and put all cores into the down status and subsequent 
recovery process.

Long way of saying, a memory circuit breaker would be very useful :)

> Provide "Circuit Breakers" For Expensive Solr Queries
> -
>
> Key: SOLR-6930
> URL: https://issues.apache.org/jira/browse/SOLR-6930
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Mike Drob
>Priority: Major
>
> Ref: 
> http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html
> ES currently allows operators to configure "circuit breakers" to preemptively 
> fail queries that are estimated too large rather than allowing an OOM 
> Exception to happen. We might be able to do the same thing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-SmokeRelease-7.5 - Build # 8 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.5/8/

No tests ran.

Build Log:
[...truncated 23297 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2430 links (1982 relative) to 3170 anchors in 245 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/solr/package/changes

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/solr/package/solr-7.5.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:

[JENKINS] Lucene-Solr-Tests-master - Build # 2818 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2818/

1 tests failed.
FAILED:  org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore.test

Error Message:
Error from server at https://127.0.0.1:33698/solr: Could not restore core

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:33698/solr: Could not restore core
at 
__randomizedtesting.SeedInfo.seed([77C9E397208DA122:FF9DDC4D8E71CCDA]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:313)
at 
org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:144)
at 
org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore.test(TestHdfsCloudBackupRestore.java:213)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Commented] (SOLR-12708) Async collection actions should not hide failures

[Mano Kovacs (JIRA)]

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

Mano Kovacs commented on SOLR-12708:


Any review would be greatly appreciated.

> Async collection actions should not hide failures
> -
>
> Key: SOLR-12708
> URL: https://issues.apache.org/jira/browse/SOLR-12708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, Backup/Restore
>Affects Versions: 7.4
>Reporter: Mano Kovacs
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Async collection API may hide failures compared to sync version. 
> [OverseerCollectionMessageHandler::processResponses|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/OverseerCollectionMessageHandler.java#L744]
>  structures errors differently in the response, that hides failures from most 
> evaluators. RestoreCmd did not receive, nor handle async addReplica issues.
> Sample create collection sync and async result with invalid solrconfig.xml:
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":32104},
> "failure":{
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard1_replica_n1': Unable to create core [name4_shard1_replica_n1] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup.",
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard2_replica_n2': Unable to create core [name4_shard2_replica_n2] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup.",
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard1_replica_n2': Unable to create core [name4_shard1_replica_n2] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup.",
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard2_replica_n1': Unable to create core [name4_shard2_replica_n1] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup."}
> }
> {noformat}
> vs async:
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":3},
> "success":{
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":12}},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":3}},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":11}},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":12}}},
> "myTaskId2709146382836":{
> "responseHeader":{
> "status":0,
> "QTime":1},
> "STATUS":"failed",
> "Response":"Error CREATEing SolrCore 'name_shard2_replica_n2': Unable to 
> create core [name_shard2_replica_n2] Caused by: The content of elements must 
> consist of well-formed character data or markup."},
> "status":{
> "state":"completed",
> "msg":"found [myTaskId] in completed tasks"}}
> {noformat}
> Proposing adding failure node to the results, keeping backward compatible but 
> correct result.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [VOTE] Release Lucene/Solr 7.5.0 RC1

[Tommaso Teofili]

+1

SUCCESS! [1:23:18.214164]
Il giorno mer 19 set 2018 alle ore 14:39 Adrien Grand
 ha scritto:
>
> +1 SUCCESS! [1:30:09.416660]
>
> Le mer. 19 sept. 2018 à 12:21, Andrzej Białecki  a écrit :
>>
>> +1
>>
>> SUCCESS! [1:42:09.201482]
>>
>>
>> On 19 Sep 2018, at 03:56, Shalin Shekhar Mangar  
>> wrote:
>>
>> +1
>>
>> SUCCESS! [0:49:21.932804]
>>
>> On Tue, Sep 18, 2018 at 9:39 PM jim ferenczi  wrote:
>>>
>>> Please vote for release candidate 1 for Lucene/Solr 7.5.0
>>>
>>> The artifacts can be downloaded from:
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
>>>
>>> You can run the smoke tester directly with this command:
>>>
>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
>>>
>>> Here's my +1
>>> SUCCESS! [1:33:42.884535]
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>>
>>
>>
>> —
>>
>> Andrzej Białecki

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

Re: [VOTE] Release Lucene/Solr 7.5.0 RC1

[Adrien Grand]

+1 SUCCESS! [1:30:09.416660]

Le mer. 19 sept. 2018 à 12:21, Andrzej Białecki  a écrit :

> +1
>
> SUCCESS! [1:42:09.201482]
>
>
> On 19 Sep 2018, at 03:56, Shalin Shekhar Mangar 
> wrote:
>
> +1
>
> SUCCESS! [0:49:21.932804]
>
> On Tue, Sep 18, 2018 at 9:39 PM jim ferenczi  wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 7.5.0
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
>>
>> Here's my +1
>> SUCCESS! [1:33:42.884535]
>>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
>
>
>
> —
>
> Andrzej Białecki
>

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 158 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/158/

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction.testNodeAdded

Error Message:
ComputePlanAction should have computed exactly 1 operation, but was: 
[org.apache.solr.client.solrj.request.CollectionAdminRequest$MoveReplica@6661c851,
 
org.apache.solr.client.solrj.request.CollectionAdminRequest$MoveReplica@cf42c2c]
 expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: ComputePlanAction should have computed exactly 1 
operation, but was: 
[org.apache.solr.client.solrj.request.CollectionAdminRequest$MoveReplica@6661c851,
 
org.apache.solr.client.solrj.request.CollectionAdminRequest$MoveReplica@cf42c2c]
 expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([3A25CF0747D0739C:5FE69970E573DB9F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction.testNodeAdded(TestSimComputePlanAction.java:314)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (SOLR-12775) Add a deprecated implementation of LowerCaseTokenizer

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-12775:
--

I'd argue that a rolling upgrade should work the other way round.  You restart 
everything, and then the logs tell you what's deprecated and needs to be 
changed before the next go-around.  Inspecting large schemas and trying to find 
everything that's been deprecated by hand makes it easy to miss things - why 
not let the code do it for you instead?

> Add a deprecated implementation of LowerCaseTokenizer
> -
>
> Key: SOLR-12775
> URL: https://issues.apache.org/jira/browse/SOLR-12775
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-12775.patch
>
>
> LUCENE-8498 will remove LowerCaseTokenizer and LowerCaseTokenizerFactory from 
> lucene 8.  To make upgrading from Solr 7.x to Solr 8 easier for users who 
> have schemas that use LowerCaseTokenizerFactory, we should add a deprecated 
> copy of the code to the {{org.apache.solr.analysis}} package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12775) Add a deprecated implementation of LowerCaseTokenizer

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12775:
-

That's a great user experience; sure.  Please go ahead with your patch if you 
like.  I was trying to articulate there are trade-offs including the extra 
effort both up front and for some future removal event.  I don't think we have 
to hold ourselves to this level of back-compat experience (i.e. need not insist 
they get a logged message for use of something deprecated).

> Add a deprecated implementation of LowerCaseTokenizer
> -
>
> Key: SOLR-12775
> URL: https://issues.apache.org/jira/browse/SOLR-12775
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-12775.patch
>
>
> LUCENE-8498 will remove LowerCaseTokenizer and LowerCaseTokenizerFactory from 
> lucene 8.  To make upgrading from Solr 7.x to Solr 8 easier for users who 
> have schemas that use LowerCaseTokenizerFactory, we should add a deprecated 
> copy of the code to the {{org.apache.solr.analysis}} package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 322 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/322/

No tests ran.

Build Log:
[...truncated 23296 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2431 links (1982 relative) to 3170 anchors in 245 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/changes

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/solr-7.6.0.tgz
 into 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings 

[jira] [Commented] (SOLR-12783) Slow queries log print status [-1] for potentially 500 error code

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-12783:
-

Attaching patch within initializing {{statusCode}} to be {{500}}, all test pass.

>  Slow queries log print status [-1] for potentially 500 error code
> --
>
> Key: SOLR-12783
> URL: https://issues.apache.org/jira/browse/SOLR-12783
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (8.0)
>Reporter: Amrit Sarkar
>Priority: Major
>
> For {{slow}} queries on {{update}}/{{select}} handler, we receive status 
> {{-1}} at number of occasions;
> {code:java}
> WARN - 2018-09-17 17:37:16.683; org.apache.solr.core.SolrCore; slow: 
> [collection_shard2_replica0] webapp=/solr path=/update 
> params={wt=javabin=2} status=-1 QTime=61066
> ERROR - 2018-09-17 17:37:16.683; org.apache.solr.common.SolrException; 
> null:org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException:
>  Async exception during distribute
> d update: Read timed out
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:972)
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1911)
> at 
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:529)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
> 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:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> 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 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
> at java.lang.Thread.run(Thread.java:745)
> WARN - 2018-09-17 17:37:16.683; org.apache.solr.servlet.ResponseUtils; 
> invalid return code: -1{code}
> statusCode *-1* doesn't indicate anything; and appropriate HTTP response code 
> will be better.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: 

[jira] [Updated] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field

[Charles Sanders (JIRA)]

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

Charles Sanders updated SOLR-5163:
--
Attachment: SOLR-5163.patch

> edismax should throw exception when qf refers to nonexistent field
> --
>
> Key: SOLR-5163
> URL: https://issues.apache.org/jira/browse/SOLR-5163
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 4.10.4
>Reporter: Steven Bower
>Assignee: David Smiley
>Priority: Major
>  Labels: newdev
> Attachments: SOLR-5163.patch, SOLR-5163.patch
>
>
> query:
> q=foo AND bar
> qf=field1
> qf=field2
> defType=edismax
> Where field1 exists and field2 doesn't..
> will treat the AND as a term vs and operator



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field

[Charles Sanders (JIRA)]

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

Charles Sanders commented on SOLR-5163:
---

Attached a new patch file.  The first attempt did not take into account field 
aliases.  Had to take a slightly different approach.  Added a unit test for the 
validation.  All unit tests pass.  I think I have addressed all previous 
comments.  As always, feedback appreciated.

> edismax should throw exception when qf refers to nonexistent field
> --
>
> Key: SOLR-5163
> URL: https://issues.apache.org/jira/browse/SOLR-5163
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 4.10.4
>Reporter: Steven Bower
>Assignee: David Smiley
>Priority: Major
>  Labels: newdev
> Attachments: SOLR-5163.patch, SOLR-5163.patch
>
>
> query:
> q=foo AND bar
> qf=field1
> qf=field2
> defType=edismax
> Where field1 exists and field2 doesn't..
> will treat the AND as a term vs and operator



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-6930:
-

I agree as well.  We have been using timeAllowed but i'll vote for something 
more sophisticated which can prevent OOM more predictably. 

> Provide "Circuit Breakers" For Expensive Solr Queries
> -
>
> Key: SOLR-6930
> URL: https://issues.apache.org/jira/browse/SOLR-6930
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Mike Drob
>Priority: Major
>
> Ref: 
> http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html
> ES currently allows operators to configure "circuit breakers" to preemptively 
> fail queries that are estimated too large rather than allowing an OOM 
> Exception to happen. We might be able to do the same thing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_172) - Build # 2772 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2772/
Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:45281/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:33589/solr/MoveReplicaHDFSTest_failed_coll_true]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[https://127.0.0.1:45281/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:33589/solr/MoveReplicaHDFSTest_failed_coll_true]
at 
__randomizedtesting.SeedInfo.seed([99A8A2A31F1AE205:33657151A8C937D5]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:994)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:289)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

Re: [VOTE] Release Lucene/Solr 7.5.0 RC1

[Nhat Nguyen]

+1 SUCCESS! [0:55:45.936280]

> On Sep 19, 2018, at 8:56 AM, Tommaso Teofili  
> wrote:
> 
> +1
> 
> SUCCESS! [1:23:18.214164]
> Il giorno mer 19 set 2018 alle ore 14:39 Adrien Grand
>  ha scritto:
>> 
>> +1 SUCCESS! [1:30:09.416660]
>> 
>> Le mer. 19 sept. 2018 à 12:21, Andrzej Białecki  a écrit :
>>> 
>>> +1
>>> 
>>> SUCCESS! [1:42:09.201482]
>>> 
>>> 
>>> On 19 Sep 2018, at 03:56, Shalin Shekhar Mangar  
>>> wrote:
>>> 
>>> +1
>>> 
>>> SUCCESS! [0:49:21.932804]
>>> 
>>> On Tue, Sep 18, 2018 at 9:39 PM jim ferenczi  wrote:
 
 Please vote for release candidate 1 for Lucene/Solr 7.5.0
 
 The artifacts can be downloaded from:
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
 
 You can run the smoke tester directly with this command:
 
 python3 -u dev-tools/scripts/smokeTestRelease.py \
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
 
 Here's my +1
 SUCCESS! [1:33:42.884535]
>>> 
>>> 
>>> 
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>> 
>>> 
>>> 
>>> 
>>> —
>>> 
>>> Andrzej Białecki
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Commented] (LUCENE-8498) Deprecate/Remove LowerCaseTokenizer

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-8498:
---

Patch removing the methods from CharTokenizer as well.  Will commit tomorrow.

> Deprecate/Remove LowerCaseTokenizer
> ---
>
> Key: LUCENE-8498
> URL: https://issues.apache.org/jira/browse/LUCENE-8498
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8498.patch, LUCENE-8498.patch
>
>
> LowerCaseTokenizer combines tokenization and filtering in a way that prevents 
> us improving the normalization API.  We should deprecate and remove it, as it 
> can be replaced simply with a LetterTokenizer and LowerCaseFilter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (LUCENE-8498) Deprecate/Remove LowerCaseTokenizer

[Alan Woodward (JIRA)]

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

Alan Woodward updated LUCENE-8498:
--
Attachment: LUCENE-8498.patch

> Deprecate/Remove LowerCaseTokenizer
> ---
>
> Key: LUCENE-8498
> URL: https://issues.apache.org/jira/browse/LUCENE-8498
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8498.patch, LUCENE-8498.patch
>
>
> LowerCaseTokenizer combines tokenization and filtering in a way that prevents 
> us improving the normalization API.  We should deprecate and remove it, as it 
> can be replaced simply with a LetterTokenizer and LowerCaseFilter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-BadApples-master-Linux (32bit/jdk1.8.0_172) - Build # 95 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/95/
Java: 32bit/jdk1.8.0_172 -server -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.cloud.SSLMigrationTest.test

Error Message:
Replica didn't have the proper urlScheme in the ClusterState

Stack Trace:
java.lang.AssertionError: Replica didn't have the proper urlScheme in the 
ClusterState
at 
__randomizedtesting.SeedInfo.seed([B6187F9C7D79B82:8335B823692BF67A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SSLMigrationTest.assertReplicaInformation(SSLMigrationTest.java:104)
at 
org.apache.solr.cloud.SSLMigrationTest.testMigrateSSL(SSLMigrationTest.java:97)
at org.apache.solr.cloud.SSLMigrationTest.test(SSLMigrationTest.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1008)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[GitHub] lucene-solr pull request #455: WIP: SOLR-12638

[moshebla]

Github user moshebla commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/455#discussion_r219034542
  
--- Diff: 
solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java
 ---
@@ -1184,7 +1196,16 @@ protected boolean versionAdd(AddUpdateCommand cmd) 
throws IOException {
 
 // TODO: possibly set checkDeleteByQueries as a flag on the 
command?
 doLocalAdd(cmd);
-
+
+if(lastKnownVersion != null && 
req.getSchema().isUsableForChildDocs() &&
--- End diff --

This delete ensures the updated block is the latest block, deleting all 
previous ones.


---

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

[JENKINS] Lucene-Solr-repro - Build # 1504 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/1504/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/163/consoleText

[repro] Revision: dad8efae3bb021726cb867e8fcf25f757c7f2399

[repro] Repro line:  ant test  -Dtestcase=TestDistribIDF 
-Dtests.method=testMultiCollectionQuery -Dtests.seed=D9D1A6ABF62AB6B0 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=en-NZ -Dtests.timezone=IST -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestTlogReplica 
-Dtests.seed=D9D1A6ABF62AB6B0 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=be -Dtests.timezone=Pacific/Pitcairn 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=SearchRateTriggerIntegrationTest 
-Dtests.method=testDeleteNode -Dtests.seed=D9D1A6ABF62AB6B0 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=fr-CA -Dtests.timezone=Europe/London -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
d494f6be13a585c273c6a3dabc76644f4d480c31
[repro] git fetch
[repro] git checkout dad8efae3bb021726cb867e8fcf25f757c7f2399

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TestDistribIDF
[repro]   TestTlogReplica
[repro]   SearchRateTriggerIntegrationTest
[repro] ant compile-test

[...truncated 3437 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.TestDistribIDF|*.TestTlogReplica|*.SearchRateTriggerIntegrationTest"
 -Dtests.showOutput=onerror  -Dtests.seed=D9D1A6ABF62AB6B0 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=en-NZ 
-Dtests.timezone=IST -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[...truncated 16572 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.TestTlogReplica
[repro]   0/5 failed: org.apache.solr.search.stats.TestDistribIDF
[repro]   3/5 failed: 
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest
[repro] git checkout d494f6be13a585c273c6a3dabc76644f4d480c31

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

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

[jira] [Commented] (LUCENE-8482) Boosting by geo distance

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8482:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  8s{color} 
| {color:red} LUCENE-8482 does not apply to master. Rebase required? Wrong 
Branch? See 
https://wiki.apache.org/lucene-java/HowToContribute#Contributing_your_work for 
help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8482 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12940356/LUCENE-8482.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/95/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Boosting by geo distance
> 
>
> Key: LUCENE-8482
> URL: https://issues.apache.org/jira/browse/LUCENE-8482
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Ignacio Vera
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: LUCENE-8482.patch, LUCENE-8482.patch, LUCENE-8482.patch
>
>
> Similarly to LUCENE-8340 it would be nice to have an easy and efficient way 
> to fold geo distance into scoring formulas in order to boost by proximity.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12782) UninvertingReader can be avoided if there are no fields to uninvert

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12782:
-

The UninvertingReader adds extremely little overhead so it's not really a big 
deal to avoid wrapping another reader.  Another possibility is to make building 
the FieldInfos lazy on the first call to UninvertingReader.getFieldInfos().  In 
this circumstance, it'd always wrap (though I still like the static wrap 
method).  However, the main user of this, SolrIndexSearcher, wraps a 
SolrCompositeReaderWrapper around the reader (which will contain 
UninvertingReader), and SCRW eagerly grabs the FieldInfos via 
MultiFields.getFields/LeafReaderFields.  Shrug.

I was also looking at IndexSchema.getUninversionMap(reader):Map.  It's a shame 
to see this method call MultiFields.getMergedFieldInfos(reader) and do all this 
looping.  It might not be heavy but nonetheless it seems unnecessary.  I think 
we don't need this method as it's largely redundant with checking that 
UninvertingReader does already or nearly does with slightly more conditions.  
All we need is a simple mapping of field name to Uninverting.Type.  This could 
be done with a lambda and needn't insist on a Map.  I'm trying this out and 
so-far-so good.

> UninvertingReader can be avoided if there are no fields to uninvert
> ---
>
> Key: SOLR-12782
> URL: https://issues.apache.org/jira/browse/SOLR-12782
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12782.patch
>
>
> Solr uses UninvertingReader to expose DocValues on fields that don't have 
> them, but do have indexed fields that can be inverted via the FieldCache. It 
> has an internal constructor that takes the input LeafReader and a mapping of 
> field name to UninvertingReader.Type. It builds a new FieldInfos that have 
> fields reflecting DocValues. There are two things I'd like to improve here:
>  # make this constructor private and instead insist you use a new wrap() 
> method that has the opportunity to return the input if there is nothing to 
> do. Effectively the logic today would move into this wrap method, and the 
> current constructor would be dead simple, and would take the FieldInfos.
>  # Do _not_ create a new {{FieldInfo}} object if the existing field is 
> suitable (it's DocValuesType can stay the same).  The savings here can really 
> add up on machines with many indexes & segments.  This is in fact what 
> motivated the patch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12784) SOLR Documentation "Link Not Found"

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12784:


Commit 81f8093b793c93aee6996d0fff0e44f5e3253445 in lucene-solr's branch 
refs/heads/branch_7x from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=81f8093 ]

SOLR-12784: Fix broken link to stemdict.txt by including it in the Guide 
directly


> SOLR Documentation "Link Not Found"
> ---
>
> Key: SOLR-12784
> URL: https://issues.apache.org/jira/browse/SOLR-12784
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.4
>Reporter: Stephen Lewis Bianamara
>Assignee: Cassandra Targett
>Priority: Major
>  Labels: Documentation
>
> This page has a broken link for at least two SOLR versions I checked (7.4 and 
> 6.6)
> https://lucene.apache.org/solr/guide/7_4/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory
>  
> [https://lucene.apache.org/solr/guide/6_6/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory]
> The broken link is an example to stemdict.txt and reports
> """
> The requested URL 
> /repos/asf/lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/stemdict.txt
>  was not found on this server.
> """



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12784) SOLR Documentation "Link Not Found"

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12784:


Commit 405a3004e6aa88bc2719ae12f6172b0d890e8ac0 in lucene-solr's branch 
refs/heads/branch_7_5 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=405a300 ]

SOLR-12784: Fix broken link to stemdict.txt by including it in the Guide 
directly


> SOLR Documentation "Link Not Found"
> ---
>
> Key: SOLR-12784
> URL: https://issues.apache.org/jira/browse/SOLR-12784
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.4
>Reporter: Stephen Lewis Bianamara
>Assignee: Cassandra Targett
>Priority: Major
>  Labels: Documentation
>
> This page has a broken link for at least two SOLR versions I checked (7.4 and 
> 6.6)
> https://lucene.apache.org/solr/guide/7_4/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory
>  
> [https://lucene.apache.org/solr/guide/6_6/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory]
> The broken link is an example to stemdict.txt and reports
> """
> The requested URL 
> /repos/asf/lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/stemdict.txt
>  was not found on this server.
> """



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12784) SOLR Documentation "Link Not Found"

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12784:


Commit 264110e7b92fdca471db593390901c632cb83bcb in lucene-solr's branch 
refs/heads/master from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=264110e ]

SOLR-12784: Fix broken link to stemdict.txt by including it in the Guide 
directly


> SOLR Documentation "Link Not Found"
> ---
>
> Key: SOLR-12784
> URL: https://issues.apache.org/jira/browse/SOLR-12784
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.4
>Reporter: Stephen Lewis Bianamara
>Assignee: Cassandra Targett
>Priority: Major
>  Labels: Documentation
>
> This page has a broken link for at least two SOLR versions I checked (7.4 and 
> 6.6)
> https://lucene.apache.org/solr/guide/7_4/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory
>  
> [https://lucene.apache.org/solr/guide/6_6/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory]
> The broken link is an example to stemdict.txt and reports
> """
> The requested URL 
> /repos/asf/lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/stemdict.txt
>  was not found on this server.
> """



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SOLR-12784) SOLR Documentation "Link Not Found"

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-12784.
--
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.6

I fixed this by using a rule ("include directive" is the proper term) to pull 
the content directly from the file in the test resources directory where it 
lives into the language-analysis.adoc page when the Guide is being built.

I backported the change into branch_7_5, but since the VOTE for the 7.5 Ref 
Guide is underway, it's likely too late to make it into the 7.5 Guide unless 
there is a more compelling reason for a respin of that release candidate. But 
if we need one, it will be included. 

It will be fixed in 7.6, however (or 8.0, whichever comes first).

> SOLR Documentation "Link Not Found"
> ---
>
> Key: SOLR-12784
> URL: https://issues.apache.org/jira/browse/SOLR-12784
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.4
>Reporter: Stephen Lewis Bianamara
>Assignee: Cassandra Targett
>Priority: Major
>  Labels: Documentation
> Fix For: 7.6, master (8.0)
>
>
> This page has a broken link for at least two SOLR versions I checked (7.4 and 
> 6.6)
> https://lucene.apache.org/solr/guide/7_4/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory
>  
> [https://lucene.apache.org/solr/guide/6_6/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory]
> The broken link is an example to stemdict.txt and reports
> """
> The requested URL 
> /repos/asf/lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/stemdict.txt
>  was not found on this server.
> """



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-10.0.1) - Build # 22887 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22887/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger

Error Message:
expected:<3> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([A64108481CFDC09C:C58A3ECA8532B3B1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.scheduledTriggerTest(ScheduledTriggerTest.java:113)
at 
org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger(ScheduledTriggerTest.java:66)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  

[jira] [Commented] (LUCENE-8484) Drop fully deleted reader in SubReaderWrapper

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-8484:
-

[~dnhatn] LGTM

> Drop fully deleted reader in SubReaderWrapper
> -
>
> Key: LUCENE-8484
> URL: https://issues.apache.org/jira/browse/LUCENE-8484
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Minor
> Fix For: 7.5, master (8.0)
>
> Attachments: LUCENE-8484.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Today we can only wrap readers in SubReaderWrapper but never filter them out
> entirely. This causes a invariant for soft-deletes that exposes fully deleted
> segments with SoftDeletesDirectoryReaderWrapper. This change drops fully 
> deleted readers after they are wrapped.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8482) Boosting by geo distance

[ASF subversion and git services (JIRA)]

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

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

Commit 10060a6237ccd2785f6cbe248ca7254028f8eb04 in lucene-solr's branch 
refs/heads/master from iverase
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=10060a6 ]

LUCENE-8482: Added feature query in LatLonPoint to boost results by distance


> Boosting by geo distance
> 
>
> Key: LUCENE-8482
> URL: https://issues.apache.org/jira/browse/LUCENE-8482
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8482.patch, LUCENE-8482.patch, LUCENE-8482.patch
>
>
> Similarly to LUCENE-8340 it would be nice to have an easy and efficient way 
> to fold geo distance into scoring formulas in order to boost by proximity.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (LUCENE-8482) Boosting by geo distance

[Ignacio Vera (JIRA)]

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

Ignacio Vera reassigned LUCENE-8482:


   Resolution: Fixed
 Assignee: Ignacio Vera
Fix Version/s: master (8.0)

Thanks [~jpountz], latest recommendations where added to the commit.

> Boosting by geo distance
> 
>
> Key: LUCENE-8482
> URL: https://issues.apache.org/jira/browse/LUCENE-8482
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Ignacio Vera
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: LUCENE-8482.patch, LUCENE-8482.patch, LUCENE-8482.patch
>
>
> Similarly to LUCENE-8340 it would be nice to have an easy and efficient way 
> to fold geo distance into scoring formulas in order to boost by proximity.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-Tests-7.5 - Build # 13 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.5/13/

2 tests failed.
FAILED:  
org.apache.solr.cloud.TestLeaderInitiatedRecoveryThread.testPublishDownState

Error Message:
expected:<27> but was:<28>

Stack Trace:
java.lang.AssertionError: expected:<27> but was:<28>
at 
__randomizedtesting.SeedInfo.seed([F01E17E124D639B4:AE63B51F80CB7049]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestLeaderInitiatedRecoveryThread.testPublishDownState(TestLeaderInitiatedRecoveryThread.java:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1008)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-8352) Make TokenStreamComponents final

[ASF subversion and git services (JIRA)]

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

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

Commit c696cafc0d7fc0e133df20e0b188655fa020fe99 in lucene-solr's branch 
refs/heads/master from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c696caf ]

LUCENE-8352: Make TokenStreamComponents final


> Make TokenStreamComponents final
> 
>
> Key: LUCENE-8352
> URL: https://issues.apache.org/jira/browse/LUCENE-8352
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mark Harwood
>Priority: Minor
> Attachments: LUCENE-8352.patch, LUCENE-8352.patch
>
>
> The current design is a little trappy. Any specialised subclasses of 
> TokenStreamComponents _(see_ _StandardAnalyzer, ClassicAnalyzer, 
> UAX29URLEmailAnalyzer)_ are discarded by any subsequent Analyzers that wrap 
> them _(see LimitTokenCountAnalyzer, QueryAutoStopWordAnalyzer, 
> ShingleAnalyzerWrapper and other examples in elasticsearch)_. 
> The current design means each AnalyzerWrapper.wrapComponents() implementation 
> discards any custom TokenStreamComponents and replaces it with one of its own 
> choosing (a vanilla TokenStreamComponents class from examples I've seen).
> This is a trap I fell into when writing a custom TokenStreamComponents with a 
> custom setReader() and I wondered why it was not being triggered when wrapped 
> by other analyzers.
> If AnalyzerWrapper is designed to encourage composition it's arguably a 
> mistake to also permit custom TokenStreamComponent subclasses  - the 
> composition process does not preserve the choice of custom classes and any 
> behaviours they might add. For this reason we should not encourage extensions 
> to TokenStreamComponents (or if TSC extensions are required we should somehow 
> mark an Analyzer as "unwrappable" to prevent lossy compositions).
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (LUCENE-8352) Make TokenStreamComponents final

[Alan Woodward (JIRA)]

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

Alan Woodward resolved LUCENE-8352.
---
   Resolution: Fixed
 Assignee: Alan Woodward
Fix Version/s: master (8.0)

> Make TokenStreamComponents final
> 
>
> Key: LUCENE-8352
> URL: https://issues.apache.org/jira/browse/LUCENE-8352
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mark Harwood
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: LUCENE-8352.patch, LUCENE-8352.patch
>
>
> The current design is a little trappy. Any specialised subclasses of 
> TokenStreamComponents _(see_ _StandardAnalyzer, ClassicAnalyzer, 
> UAX29URLEmailAnalyzer)_ are discarded by any subsequent Analyzers that wrap 
> them _(see LimitTokenCountAnalyzer, QueryAutoStopWordAnalyzer, 
> ShingleAnalyzerWrapper and other examples in elasticsearch)_. 
> The current design means each AnalyzerWrapper.wrapComponents() implementation 
> discards any custom TokenStreamComponents and replaces it with one of its own 
> choosing (a vanilla TokenStreamComponents class from examples I've seen).
> This is a trap I fell into when writing a custom TokenStreamComponents with a 
> custom setReader() and I wondered why it was not being triggered when wrapped 
> by other analyzers.
> If AnalyzerWrapper is designed to encourage composition it's arguably a 
> mistake to also permit custom TokenStreamComponent subclasses  - the 
> composition process does not preserve the choice of custom classes and any 
> behaviours they might add. For this reason we should not encourage extensions 
> to TokenStreamComponents (or if TSC extensions are required we should somehow 
> mark an Analyzer as "unwrappable" to prevent lossy compositions).
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8508) Add the ability to set the version that created the index

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8508:


| (x) *{color:red}-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 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
23s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
19s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  0m 19s{color} 
| {color:red} lucene_core generated 2 new + 6 unchanged - 0 fixed = 8 total 
(was 6) {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 19s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m  
9s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 13m 29s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8508 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12940243/LUCENE-8508.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-130-generic #156~14.04.1-Ubuntu SMP Thu 
Jun 14 13:51:47 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 / c696caf |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_172 |
| javac | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/94/artifact/out/diff-compile-javac-lucene_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/94/testReport/ |
| modules | C: lucene/core U: lucene/core |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/94/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Add the ability to set the version that created the index
> -
>
> Key: LUCENE-8508
> URL: https://issues.apache.org/jira/browse/LUCENE-8508
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8508.patch
>
>
> It is sometimes useful to be able to set the creation version of an index. 
> For instance in a sharded environment, it may be useful to make sure that all 
> indices are created with the same major in order to be able to 
> increase/reduce the number of shards later on using IndexWriter#addIndexes. 
> This is an expert feature.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+28) - Build # 22884 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22884/
Java: 64bit/jdk-11-ea+28 -XX:-UseCompressedOops -XX:+UseG1GC

20 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest: 1) 
Thread[id=2012, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-LargeVolumeJettyTest] at 
java.base@11/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11/java.lang.Thread.run(Thread.java:834)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest: 
   1) Thread[id=2012, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-LargeVolumeJettyTest]
at java.base@11/java.lang.Thread.sleep(Native Method)
at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.base@11/java.lang.Thread.run(Thread.java:834)
at __randomizedtesting.SeedInfo.seed([37AFAE9146EAD57E]:0)


FAILED:  
org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest.testMultiThreaded

Error Message:
Captured an uncaught exception in thread: Thread[id=2011, name=DocThread-1, 
state=RUNNABLE, group=TGRP-LargeVolumeJettyTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=2011, name=DocThread-1, state=RUNNABLE, 
group=TGRP-LargeVolumeJettyTest]
Caused by: java.lang.AssertionError: DocThread-1---IOException occured when 
talking to server at: https://127.0.0.1:45231/solr/collection1
at __randomizedtesting.SeedInfo.seed([37AFAE9146EAD57E]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.client.solrj.LargeVolumeTestBase$DocThread.run(LargeVolumeTestBase.java:128)


FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.preferReplicaTypesTest

Error Message:
Could not find collection:replicaTypesTestColl

Stack Trace:
java.lang.AssertionError: Could not find collection:replicaTypesTestColl
at 
__randomizedtesting.SeedInfo.seed([37AFAE9146EAD57E:C450D2721731872]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.preferReplicaTypesTest(CloudSolrClientTest.java:869)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 

[JENKINS] Lucene-Solr-BadApples-NightlyTests-7.x - Build # 27 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-7.x/27/

2 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at http://127.0.0.1:36748/solr/awhollynewcollection_0: No 
registered leader was found after waiting for 4000ms , collection: 
awhollynewcollection_0 slice: shard1 saw 
state=DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/9)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{   
"range":"8000-",   "state":"active",   "replicas":{ 
"core_node3":{   "core":"awhollynewcollection_0_shard1_replica_n1", 
  "base_url":"http://127.0.0.1:42077/solr;,   
"node_name":"127.0.0.1:42077_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false"}, "core_node5":{  
 "core":"awhollynewcollection_0_shard1_replica_n2",   
"base_url":"http://127.0.0.1:41916/solr;,   
"node_name":"127.0.0.1:41916_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}}}, "shard2":{   
"range":"0-7fff",   "state":"active",   "replicas":{ 
"core_node7":{   "core":"awhollynewcollection_0_shard2_replica_n4", 
  "base_url":"http://127.0.0.1:36748/solr;,   
"node_name":"127.0.0.1:36748_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   "leader":"true"},  
   "core_node8":{   
"core":"awhollynewcollection_0_shard2_replica_n6",   
"base_url":"http://127.0.0.1:39480/solr;,   
"node_name":"127.0.0.1:39480_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0"} with 
live_nodes=[127.0.0.1:39480_solr, 127.0.0.1:36748_solr, 127.0.0.1:41916_solr, 
127.0.0.1:42077_solr]

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36748/solr/awhollynewcollection_0: No 
registered leader was found after waiting for 4000ms , collection: 
awhollynewcollection_0 slice: shard1 saw 
state=DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/9)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{
"shard1":{
  "range":"8000-",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"awhollynewcollection_0_shard1_replica_n1",
  "base_url":"http://127.0.0.1:42077/solr;,
  "node_name":"127.0.0.1:42077_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false"},
"core_node5":{
  "core":"awhollynewcollection_0_shard1_replica_n2",
  "base_url":"http://127.0.0.1:41916/solr;,
  "node_name":"127.0.0.1:41916_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false"}}},
"shard2":{
  "range":"0-7fff",
  "state":"active",
  "replicas":{
"core_node7":{
  "core":"awhollynewcollection_0_shard2_replica_n4",
  "base_url":"http://127.0.0.1:36748/solr;,
  "node_name":"127.0.0.1:36748_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true"},
"core_node8":{
  "core":"awhollynewcollection_0_shard2_replica_n6",
  "base_url":"http://127.0.0.1:39480/solr;,
  "node_name":"127.0.0.1:39480_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"} with live_nodes=[127.0.0.1:39480_solr, 
127.0.0.1:36748_solr, 127.0.0.1:41916_solr, 127.0.0.1:42077_solr]
at 
__randomizedtesting.SeedInfo.seed([7AFC356D37802C31:328941D931B303A4]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 

[jira] [Commented] (LUCENE-8482) Boosting by geo distance

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-8482:
--

Attached a new patch with the following changes:

1) Change maxDistance to  EARTH_MEAN_RADIUS_METERS * Math.PI. You are right, it 
should be the surface distance.

2) Added a new test that compares sorting.

I have tried removing the byte[] comparison in  IntersectVisitor#visit() and 
there was a small decrease in performance.

> Boosting by geo distance
> 
>
> Key: LUCENE-8482
> URL: https://issues.apache.org/jira/browse/LUCENE-8482
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8482.patch, LUCENE-8482.patch, LUCENE-8482.patch
>
>
> Similarly to LUCENE-8340 it would be nice to have an easy and efficient way 
> to fold geo distance into scoring formulas in order to boost by proximity.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

***UNCHECKED*** [jira] [Commented] (LUCENE-8482) Boosting by geo distance

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8482:
--

+1 patch looks great. One minor issue with the explanation string: it contains 
"abs(value - origin)" which doesn't make sense here, let's say something like 
"distance" instead? Also it might be useful to add the distance to the sub 
explanations?

Thanks for also testing with a lossy bounding box.

> Boosting by geo distance
> 
>
> Key: LUCENE-8482
> URL: https://issues.apache.org/jira/browse/LUCENE-8482
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8482.patch, LUCENE-8482.patch, LUCENE-8482.patch
>
>
> Similarly to LUCENE-8340 it would be nice to have an easy and efficient way 
> to fold geo distance into scoring formulas in order to boost by proximity.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [VOTE] Release Lucene/Solr 7.5.0 RC1

[Andrzej Białecki]

+1

SUCCESS! [1:42:09.201482]

> On 19 Sep 2018, at 03:56, Shalin Shekhar Mangar  
> wrote:
> 
> +1
> 
> SUCCESS! [0:49:21.932804]
> 
> On Tue, Sep 18, 2018 at 9:39 PM jim ferenczi  > wrote:
> Please vote for release candidate 1 for Lucene/Solr 7.5.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
>  
> 
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
>  
> 
> 
> Here's my +1
> SUCCESS! [1:33:42.884535]
> 
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.



—

Andrzej Białecki

[jira] [Updated] (PYLUCENE-43) Failed to build PyLucene after the removal of SetuptoolsVersion in setuptools

[Xiang Zhang (JIRA)]

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

Xiang Zhang updated PYLUCENE-43:

Description: 
*Environment I'm Using*:
 * ubuntu 16.04
 * cleanly installed python 2.7.15 built with latest pyenv
 * Setuptools 40.4.1
 * pip 18.0
 * pylucene-7.4.0.tar.gz
 * jdk 1.8.0_181
 * ant 1.10. 5

*Phenomenon*

Step1. build jcc

In JCC's setup.py file, with_modern_setuptools is False by checking if 
pkg_resource.SetuptoolsVersions is available.

According to [setuptools 
developer|https://github.com/pypa/setuptools/issues/1310], this is not 
documented and is already removed, causing jcc not built with shared mode 
consequently but no error or warning is prompted.

Step2. build pylucene

The final error comes with the following line:
{code:java}
python -m jcc --shared --jar 
lucene-java-7.4.0/lucene/build/core/lucene-core-7.4.0.jar --jar 
(omitted).  --version 7.4.0 --module python/collections.py --module 
python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module 
python/ICUTransformFilter.py  --files 8 --build

(lots of warning omitted).

Traceback (most recent call last):
  File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 174, in 
_run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 72, in 
_run_code
exec code in run_globals
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/__main__.py",
 line 107, in 
cpp.jcc(sys.argv)
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/cpp.py",
 line 736, in jcc
egg_info, extra_setup_args)
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/python.py",
 line 1606, in compile
raise NotImplementedError, "JCC was not built with --shared mode support, 
see JCC's INSTALL file for more information"
NotImplementedError: JCC was not built with --shared mode support, see JCC's 
INSTALL file for more information
Makefile:349: recipe for target 'compile' failed
make: *** [compile] Error 1
{code}
It was hard to debug given that "JCC is not built with shared mode", actually I 
indeed got a _jcc.so library in the build directory.

*Quick Fix for Me*

As long as I believe the setuptools package has enough high version, I force 
the with_modern_setuptools switch to be True as the following(at line 210 in 
JCC's setup.py):
{code:java}
...
try:
from pkg_resources import SetuptoolsVersion
with_modern_setuptools = True
except ImportError:
with_modern_setuptools = False

enable_shared = False
with_modern_setuptools = True
if with_modern_setuptools and 'NO_SHARED' not in os.environ:

{code}
i.e., the helpers for linux are still working well.

then rebuilt JCC, remove the existing one and reinstall, then continue to make 
pylucene, all things work now.

  was:
*Environment I'm Using*:
 * ubuntu 16.04
 * cleanly installed python 2.7.15 built with latest pyenv
 * Setuptools 40.4.1
 * pip 18.0
 * pylucene-7.4.0.tar.gz
 * jdk 1.8.0_181
 * ant 1.10. 5

*Phenomenon*

Step1. build jcc

In JCC's setup.py file, with_modern_setuptools is False by checking if 
pkg_resource.SetuptoolsVersions is available.

According to [setuptools 
developer|https://github.com/pypa/setuptools/issues/1310], this is not 
documented and is already removed, causing jcc not built with shared mode 
consequently but no error or warning is prompted.

Step2. build pylucene

The final error comes with the following line:
{code:java}
python -m jcc --shared --jar 
lucene-java-7.4.0/lucene/build/core/lucene-core-7.4.0.jar --jar 
(omitted).  --version 7.4.0 --module python/collections.py --module 
python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module 
python/ICUTransformFilter.py  --files 8 --build

(lots of warning omitted).

Traceback (most recent call last):
  File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 174, in 
_run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 72, in 
_run_code
exec code in run_globals
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/__main__.py",
 line 107, in 
cpp.jcc(sys.argv)
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/cpp.py",
 line 736, in jcc
egg_info, extra_setup_args)
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/python.py",
 line 1606, in compile
raise NotImplementedError, "JCC was not built with --shared mode support, 
see JCC's INSTALL file for more information"
NotImplementedError: JCC was not built 

[jira] [Created] (PYLUCENE-43) Failed to build PyLucene after the removal of SetuptoolsVersion in setuptools

[Xiang Zhang (JIRA)]

Xiang Zhang created PYLUCENE-43:
---

 Summary: Failed to build PyLucene after the removal of 
SetuptoolsVersion in setuptools
 Key: PYLUCENE-43
 URL: https://issues.apache.org/jira/browse/PYLUCENE-43
 Project: PyLucene
  Issue Type: Bug
Reporter: Xiang Zhang


*Environment I'm Using*:
 * ubuntu 16.04
 * cleanly installed python 2.7.15 built with latest pyenv
 * Setuptools 40.4.1
 * pip 18.0
 * pylucene-7.4.0.tar.gz

*Phenomenon*

Step1. build jcc

In JCC's setup.py file, with_modern_setuptools is False by checking if 
pkg_resource.SetuptoolsVersions is available.

According to [setuptools 
developer|https://github.com/pypa/setuptools/issues/1310], this is not 
documented and is already removed, causing jcc not build with shared mode 
consequently but no error or warning is prompted.

Step2. build pylucene

The final error comes with the following line:
{code}
python -m jcc --shared --jar 
lucene-java-7.4.0/lucene/build/core/lucene-core-7.4.0.jar --jar 
(omitted).  --version 7.4.0 --module python/collections.py --module 
python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module 
python/ICUTransformFilter.py  --files 8 --build

(lots of warning omitted).

Traceback (most recent call last):
  File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 174, in 
_run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 72, in 
_run_code
exec code in run_globals
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/__main__.py",
 line 107, in 
cpp.jcc(sys.argv)
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/cpp.py",
 line 736, in jcc
egg_info, extra_setup_args)
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/python.py",
 line 1606, in compile
raise NotImplementedError, "JCC was not built with --shared mode support, 
see JCC's INSTALL file for more information"
NotImplementedError: JCC was not built with --shared mode support, see JCC's 
INSTALL file for more information
Makefile:349: recipe for target 'compile' failed
make: *** [compile] Error 1
{code}
It was hard to debug given that "JCC is not built with shared mode", actually I 
indeed got a _jcc.so library in the build directory.

*Quick Fix for Me*

As long as I believe the setuptools package has enough high version, I force 
the with_modern_setuptools switch to be True as the following(at line 210 in 
JCC's setup.py):
{code}
...
try:
from pkg_resources import SetuptoolsVersion
with_modern_setuptools = True
except ImportError:
with_modern_setuptools = False

enable_shared = False
with_modern_setuptools = True
if with_modern_setuptools and 'NO_SHARED' not in os.environ:

{code}
i.e., the helpers for linux are still useful

then rebuilt JCC, remove the existing one and reinstall, then continue to make 
pylucene, all things work now.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PYLUCENE-43) Failed to build PyLucene after the removal of SetuptoolsVersion in setuptools

[Xiang Zhang (JIRA)]

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

Xiang Zhang updated PYLUCENE-43:

Description: 
*Environment I'm Using*:
 * ubuntu 16.04
 * cleanly installed python 2.7.15 built with latest pyenv
 * Setuptools 40.4.1
 * pip 18.0
 * pylucene-7.4.0.tar.gz
 * jdk 1.8.0_181
 * ant 1.10. 5

*Phenomenon*

Step1. build jcc

In JCC's setup.py file, with_modern_setuptools is False by checking if 
pkg_resource.SetuptoolsVersions is available.

According to [setuptools 
developer|https://github.com/pypa/setuptools/issues/1310], this is not 
documented and is already removed, causing jcc not built with shared mode 
consequently but no error or warning is prompted.

Step2. build pylucene

The final error comes with the following line:
{code:java}
python -m jcc --shared --jar 
lucene-java-7.4.0/lucene/build/core/lucene-core-7.4.0.jar --jar 
(omitted).  --version 7.4.0 --module python/collections.py --module 
python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module 
python/ICUTransformFilter.py  --files 8 --build

(lots of warning omitted).

Traceback (most recent call last):
  File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 174, in 
_run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 72, in 
_run_code
exec code in run_globals
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/__main__.py",
 line 107, in 
cpp.jcc(sys.argv)
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/cpp.py",
 line 736, in jcc
egg_info, extra_setup_args)
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/python.py",
 line 1606, in compile
raise NotImplementedError, "JCC was not built with --shared mode support, 
see JCC's INSTALL file for more information"
NotImplementedError: JCC was not built with --shared mode support, see JCC's 
INSTALL file for more information
Makefile:349: recipe for target 'compile' failed
make: *** [compile] Error 1
{code}
It was hard to debug given that "JCC is not built with shared mode", actually I 
indeed got a _jcc.so library in the build directory.

*Quick Fix for Me*

As long as I believe the setuptools package has enough high version, I force 
the with_modern_setuptools switch to be True as the following(at line 210 in 
JCC's setup.py):
{code:java}
...
try:
from pkg_resources import SetuptoolsVersion
with_modern_setuptools = True
except ImportError:
with_modern_setuptools = False

enable_shared = False
with_modern_setuptools = True
if with_modern_setuptools and 'NO_SHARED' not in os.environ:

{code}
i.e., the helpers for linux are still useful

then rebuilt JCC, remove the existing one and reinstall, then continue to make 
pylucene, all things work now.

  was:
*Environment I'm Using*:
 * ubuntu 16.04
 * cleanly installed python 2.7.15 built with latest pyenv
 * Setuptools 40.4.1
 * pip 18.0
 * pylucene-7.4.0.tar.gz

*Phenomenon*

Step1. build jcc

In JCC's setup.py file, with_modern_setuptools is False by checking if 
pkg_resource.SetuptoolsVersions is available.

According to [setuptools 
developer|https://github.com/pypa/setuptools/issues/1310], this is not 
documented and is already removed, causing jcc not build with shared mode 
consequently but no error or warning is prompted.

Step2. build pylucene

The final error comes with the following line:
{code}
python -m jcc --shared --jar 
lucene-java-7.4.0/lucene/build/core/lucene-core-7.4.0.jar --jar 
(omitted).  --version 7.4.0 --module python/collections.py --module 
python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module 
python/ICUTransformFilter.py  --files 8 --build

(lots of warning omitted).

Traceback (most recent call last):
  File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 174, in 
_run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 72, in 
_run_code
exec code in run_globals
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/__main__.py",
 line 107, in 
cpp.jcc(sys.argv)
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/cpp.py",
 line 736, in jcc
egg_info, extra_setup_args)
  File 
"/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/python.py",
 line 1606, in compile
raise NotImplementedError, "JCC was not built with --shared mode support, 
see JCC's INSTALL file for more information"
NotImplementedError: JCC was not built with --shared mode support, see JCC's 
INSTALL 

[jira] [Resolved] (PYLUCENE-43) Failed to build PyLucene after the removal of SetuptoolsVersion in setuptools

[Andi Vajda (JIRA)]

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

Andi Vajda resolved PYLUCENE-43.

Resolution: Fixed

Hopefully fixed in rev 1841356.
The newer setuptools helpfully dropped SetuptoolsVersion.
I added another case for looking for 
  pkg_resources.extern.packaging.version import Version
which seems to be there then, sigh.
Thank you for the bug report.

> Failed to build PyLucene after the removal of SetuptoolsVersion in setuptools
> -
>
> Key: PYLUCENE-43
> URL: https://issues.apache.org/jira/browse/PYLUCENE-43
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Xiang Zhang
>Priority: Major
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> *Environment I'm Using*:
>  * ubuntu 16.04
>  * cleanly installed python 2.7.15 built with latest pyenv
>  * Setuptools 40.4.1
>  * pip 18.0
>  * pylucene-7.4.0.tar.gz
>  * jdk 1.8.0_181
>  * ant 1.10. 5
> *Phenomenon*
> Step1. build jcc
> In JCC's setup.py file, with_modern_setuptools is False by checking if 
> pkg_resource.SetuptoolsVersions is available.
> According to [setuptools 
> developer|https://github.com/pypa/setuptools/issues/1310], this is not 
> documented and is already removed, causing jcc not built with shared mode 
> consequently but no error or warning is prompted.
> Step2. build pylucene
> The final error comes with the following line:
> {code:java}
> python -m jcc --shared --jar 
> lucene-java-7.4.0/lucene/build/core/lucene-core-7.4.0.jar --jar 
> (omitted).  --version 7.4.0 --module python/collections.py --module 
> python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module 
> python/ICUTransformFilter.py  --files 8 --build
> (lots of warning omitted).
> Traceback (most recent call last):
>   File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 174, 
> in _run_module_as_main
> "__main__", fname, loader, pkg_name)
>   File "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/runpy.py", line 72, 
> in _run_code
> exec code in run_globals
>   File 
> "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/__main__.py",
>  line 107, in 
> cpp.jcc(sys.argv)
>   File 
> "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/cpp.py",
>  line 736, in jcc
> egg_info, extra_setup_args)
>   File 
> "/home/hesz/.pyenv/versions/2.7.15/lib/python2.7/site-packages/JCC-3.2-py2.7-linux-x86_64.egg/jcc/python.py",
>  line 1606, in compile
> raise NotImplementedError, "JCC was not built with --shared mode support, 
> see JCC's INSTALL file for more information"
> NotImplementedError: JCC was not built with --shared mode support, see JCC's 
> INSTALL file for more information
> Makefile:349: recipe for target 'compile' failed
> make: *** [compile] Error 1
> {code}
> It was hard to debug given that "JCC is not built with shared mode", actually 
> I indeed got a _jcc.so library in the build directory.
> *Quick Fix for Me*
> As long as I believe the setuptools package has enough high version, I force 
> the with_modern_setuptools switch to be True as the following(at line 210 in 
> JCC's setup.py):
> {code:java}
> ...
> try:
> from pkg_resources import SetuptoolsVersion
> with_modern_setuptools = True
> except ImportError:
> with_modern_setuptools = False
> enable_shared = False
> with_modern_setuptools = True
> if with_modern_setuptools and 'NO_SHARED' not in os.environ:
> 
> {code}
> i.e., the helpers for linux are still working well.
> then rebuilt JCC, remove the existing one and reinstall, then continue to 
> make pylucene, all things work now.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)