[JENKINS] Lucene-Solr-Tests-master - Build # 3342 - Still Failing

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI

Error Message:
{} expected:<2> but was:<0>

Stack Trace:
java.lang.AssertionError: {} expected:<2> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([579AAEF77EB9E494:484D32DB0DB21DDF]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:293)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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:834)




Build Log:
[...truncated 14003 lines...]
   [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-13437) fork noggit code to Solr

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-13437:
-

bq. /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:494: Source 
checkout is dirty (unversioned/missing files) after running tests!!! Offending 
files:

This is generally indicative of unclean workspace while running precommit. Not 
sure what's going on in that box.

> fork noggit code to Solr
> 
>
> Key: SOLR-13437
> URL: https://issues.apache.org/jira/browse/SOLR-13437
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> We rely on noggit for all our JSON encoding/decoding needs.The main project 
> is not actively maintained . We cannot easily switch to another parser 
> because it may cause backward incompatibility and we have advertised the 
> ability to use flexible JSON and we also use noggit internally in many classes



--
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-13437) fork noggit code to Solr

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-13437:
-

It passes for me too.

> fork noggit code to Solr
> 
>
> Key: SOLR-13437
> URL: https://issues.apache.org/jira/browse/SOLR-13437
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> We rely on noggit for all our JSON encoding/decoding needs.The main project 
> is not actively maintained . We cannot easily switch to another parser 
> because it may cause backward incompatibility and we have advertised the 
> ability to use flexible JSON and we also use noggit internally in many classes



--
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: ReleaseWizard tool

[Ishan Chattopadhyaya]

Much needed. Thanks for working on it.

Here's an idea I was thinking about yesterday: the most tedious step is to
generate release highlights. We should have a JIRA field "release
highlight" which, when populated, will have the text that will be featured
in the announce mail and on the website in news. That way, generating those
mails can be semi/fully automated.

Alternatively, this field can just be a Boolean check box and title of the
Jira can be used as highlight. This will force the committer to keep
meaningful titles.

On Thu, 16 May, 2019, 10:58 PM Jan Høydahl,  wrote:

> Just a heads-up that as part of my releasing 7.7.2 effort I'm also hacking
> on
> a releaseWizard script to replace the ReleaseTodo wiki page. It will act
> as a
> checklist where you see tasks that needs to be done (different for
> major/minor/bug)
> and mark those completed. It will also run all the commands for you and
> preserve
> the logs, generate e-mail templates with all versions, dates etc in place,
> handle
> voting rules and counting etc. It will also generate an asciidoc + HTML
> page that
> gives a nice overview of the whole thing :)
>
> Here's a teaser:
>
> https://asciinema.org/a/246656
>
>
>   ┌─┐
>   │
>   │
>   │  Releasing Lucene/Solr 7.7.2 RC1
>   │
>   │
>   │
>   │  Please complete the below checklist (Complete: 4/11)
>   │
>   │
>   │
>   │
>   │
>   │1 - ✓ Prerequisites (3/3)
>   │
>   │2 - ✓ Work with the community to decide when and how etc (1/1)
>   │
>   │3 - ✓ Create branch (if needed) and update versions (4/4)
>   │
>   │4 - ✓ Add new versions to JIRA (2/2)
>   │
>   │5 - Build the release artifacts (2/3)
>   │
>   │6 - Hold the vote and sum up the results (0/2)
>   │
>   │7 - Publish the release artifacts (0/1)
>   │
>   │8 - Update the website (0/1)
>   │
>   │9 - Update the DOAP file (0/1)
>   │
>   │   10 - Announce the release (0/1)
>   │
>   │   11 - Tasks to do after release (0/1)
>   │
>   │   12 - Exit
>   │
>   │
>   │
>   │
>   │
>
> └─┘
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>

[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))

[Huy Le (JIRA)]

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

Huy Le commented on LUCENE-8041:


I don't think that we can avoid paying the additional O(N) memory cost by using 
Stream#sorted trick because under the hood, the stream implementation also 
creates an Array, sort it then copy it into the LinkedHashMap in the terminal 
stage (see SortedOps.SizedRefSortingSink).  Apart from DirectFields, it is hard 
to implement your approach on other cases. The patch I provided has advantage 
that it is simple, clear and safe. 

As we are talking about number of fields, it is unlikely that there is a index 
with million fields perhaps ten of thousands is more realistic.  

> All Fields.terms(fld) impls should be O(1) not O(log(N))
> 
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041-LinkedHashMap.patch, LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds.  The O(log(N)) 
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time, 
> if I recall.  There are many Field implementations that are impacted... in 
> part because Fields is the base class of FieldsProducer.  
> As an aside, I hope Fields to go away some day; FieldsProducer should be 
> TermsProducer and not have an iterator of fields. If DocValuesProducer 
> doesn't have this then why should the terms index part of our API have it?  
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator 
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap 
> in many cases if we can assume when we initialize these internal maps that we 
> consume them in sorted order to begin with.



--
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-8.x-Linux (32bit/jdk1.8.0_201) - Build # 572 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/572/
Java: 32bit/jdk1.8.0_201 -server -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.cloud.SystemCollectionCompatTest.testBackCompat

Error Message:
re-indexing warning not found

Stack Trace:
java.lang.AssertionError: re-indexing warning not found
at 
__randomizedtesting.SeedInfo.seed([9B33022981F5057D:EBC6A180E13DAC0B]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.SystemCollectionCompatTest.testBackCompat(SystemCollectionCompatTest.java:203)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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)


FAILED:  
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExampleWithAutoScalingPolicy

Error Message:
After running Solr cloud example, test collection 'testCloudExamplePrompt1' not 
found in Solr at: http://localhost:41683/solr; tool output:  Welcome to the 
SolrCloud 

[jira] [Commented] (SOLR-12304) Interesting Terms parameter is ignored by MLT Component

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12304:


Commit 6f83dad301a011d5e390b793ffa09bfb75fe7b48 in lucene-solr's branch 
refs/heads/branch_8x from Alessandro Benedetti
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6f83dad ]

SOLR-12304: MLT component now supports mlt.interestingTerms

(cherry picked from commit b9db118ed3f60e0eb431126a1f5401b59c22808a)


> Interesting Terms parameter is ignored by MLT Component
> ---
>
> Key: SOLR-12304
> URL: https://issues.apache.org/jira/browse/SOLR-12304
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: MoreLikeThis
>Affects Versions: 7.2
>Reporter: Alessandro Benedetti
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12304.patch, SOLR-12304.patch, SOLR-12304.patch, 
> SOLR-12304.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the More Like This component just ignores the mlt.InterestingTerms 
> parameter ( which is usable by the MoreLikeThisHandler).
> Scope of this issue is to fix the bug and add related tests ( which will 
> succeed after the fix )
> *N.B.* MoreLikeThisComponent and MoreLikeThisHandler are very coupled and the 
> tests for the MoreLikeThisHandler are intersecting the MoreLikeThisComponent 
> ones .
>  It is out of scope for this issue any consideration or refactor of that.
>  Other issues will follow.
> *N.B.* out of scope for this issue is the distributed case, which is much 
> more complicated and requires much deeper investigations



--
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-12304) Interesting Terms parameter is ignored by MLT Component

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12304:


Commit b9db118ed3f60e0eb431126a1f5401b59c22808a in lucene-solr's branch 
refs/heads/master from Alessandro Benedetti
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b9db118e ]

SOLR-12304: MLT component now supports mlt.interestingTerms


> Interesting Terms parameter is ignored by MLT Component
> ---
>
> Key: SOLR-12304
> URL: https://issues.apache.org/jira/browse/SOLR-12304
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: MoreLikeThis
>Affects Versions: 7.2
>Reporter: Alessandro Benedetti
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12304.patch, SOLR-12304.patch, SOLR-12304.patch, 
> SOLR-12304.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the More Like This component just ignores the mlt.InterestingTerms 
> parameter ( which is usable by the MoreLikeThisHandler).
> Scope of this issue is to fix the bug and add related tests ( which will 
> succeed after the fix )
> *N.B.* MoreLikeThisComponent and MoreLikeThisHandler are very coupled and the 
> tests for the MoreLikeThisHandler are intersecting the MoreLikeThisComponent 
> ones .
>  It is out of scope for this issue any consideration or refactor of that.
>  Other issues will follow.
> *N.B.* out of scope for this issue is the distributed case, which is much 
> more complicated and requires much deeper investigations



--
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-13477) Handling huge number of data in one plate

[Muthukarthik (JIRA)]

Muthukarthik created SOLR-13477:
---

 Summary: Handling huge number of data in one plate
 Key: SOLR-13477
 URL: https://issues.apache.org/jira/browse/SOLR-13477
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 6.6.5
Reporter: Muthukarthik


Team,

 We are having the problem in handling the huge number of data in one SOLR 
plate. To make it clear, We have a relation as below.  

                    Product - etect  N:N

                     etec - patetn 1:N

 

Now, We have to use patent search and it should be used us facet filters too. 
so we have indexed them in the facet configuration as per SOLR norms.

One product may have 1k or more patents. So due to this while searching we are 
experiencing the Slow or time out error.  Please guide us to resolve this as we 
already rollout to production.

 

We are using Two-phase indexing and SOLR cloud for Hybris.

 

Regards,

Muthukarthik M

 



--
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-8326) More Like This Params Refactor

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8326:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  6s{color} 
| {color:red} LUCENE-8326 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-8326 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12926768/LUCENE-8326.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/185/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> More Like This Params Refactor
> --
>
> Key: LUCENE-8326
> URL: https://issues.apache.org/jira/browse/LUCENE-8326
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/query/scoring
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: LUCENE-8326.patch, LUCENE-8326.patch, LUCENE-8326.patch, 
> LUCENE-8326.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> More Like This ca be refactored to improve the code readability, test 
> coverage and maintenance.
> Scope of this Jira issue is to start the More Like This refactor from the 
> More Like This Params.
> This Jira will not improve the current More Like This but just keep the same 
> functionality with a refactored code.
> Other Jira issues will follow improving the overall code readability, test 
> coverage and maintenance.



--
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-11872) Refactor test infra to work with a managed SolrClient; ditch TestHarness

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11872:
-

You refer to assertResponseValues specifically, added by you very recently?  
Yeah that looks good – something like assertJQ but which takes a 
SolrResponseBase instead of XML, and it appears you have done that.

I'm very glad you are interested in helping [~noble.paul] and yes I think we 
can split this up some.  I've got an important trip to prepare for that will 
consume my time for the next 7 days or so but after I can take a stab at 
outlining some tasks and their scopes for discussion here.

> Refactor test infra to work with a managed SolrClient; ditch TestHarness
> 
>
> Key: SOLR-11872
> URL: https://issues.apache.org/jira/browse/SOLR-11872
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: David Smiley
>Priority: Major
>
> This is a proposal to substantially refactor SolrTestCaseJ4 and some of its 
> intermediate subclasses in the hierarchy.  _In essence, I envision that tests 
> should work with a SolrClient typed "solrClient" field managed by the test 
> infrastructure._ With only a few lines of code, a test should be able to pick 
> between an instance based on EmbeddedSolrServer (lighter tests), 
> HttpSolrClient (tests HTTP/Jetty behavior directly or indirectly), SolrCloud, 
> and perhaps a special one for our distributed search tests. STCJ4 would 
> refactor its methods to use the solrClient field _instead of TestHarness_. 
> TestHarness would disappear as-such; bits of its existing code would migrate 
> elsewhere, such as to manage an EmbeddedSolrServer for testing.
> I think we can do a transition like this in stages and furthermore minimally 
> affecting most tests by adding some deprecated shims. Perhaps STCJ4 should 
> _become_ the deprecated shim so that users can still use it during 7.x and to 
> help us with the transition internally too. More specifically, we'd add a new 
> superclass to STCJ4 that is the future – "SolrTestCase".
> Additionally, there are a bunch of methods on SolrTestCaseJ4 that I question 
> the design of, especially ones that return XML strings like {{delI}} 
> (generates a delete-by-id XML string) and {{adoc}}. Perhaps that used to be a 
> fine idea before there was a convenient SolrClient API but we've got one now 
> and a test shouldn't be building XML unless it's trying to test exactly that.
> For consulting work I once developed a JUnit4 {{TestRule}} managing a 
> SolrClient that is declared in a test with an annotation of {{@ClassRule}}. I 
> had a variation for SolrCloud and EmbeddedSolrServer that was easy for a test 
> to choose. Since TestRule is an interface, I was able to make a special 
> delegating SolrClient subclass that implements TestRule. This isn't essential 
> but makes use of it easier since otherwise you'd be forced to call something 
> like getSolrClient(). We could go the TestRule route here, which I prefer 
> (with or without having it subclass SolrClient), or we could alternatively do 
> TestCase subclassing to manage the lifecycle.
> Initially I'm just looking for agreement and refinement of the approach. 
> After that, sub-tasks ought to be added. I won't have time to work on this 
> for some time.



--
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-8.x - Build # 200 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/200/

1 tests failed.
FAILED:  org.apache.solr.security.AuditLoggerIntegrationTest.testAsync

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

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([9B54BF0CA4175EBA:E44CB6C58B513141]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.solr.security.AuditLoggerIntegrationTest.assertThreeAdminEvents(AuditLoggerIntegrationTest.java:253)
at 
org.apache.solr.security.AuditLoggerIntegrationTest.testAsync(AuditLoggerIntegrationTest.java:109)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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)




Build Log:
[...truncated 14334 lines...]
   [junit4] Suite: org.apache.solr.security.AuditLoggerIntegrationTest
   

[JENKINS] Lucene-Solr-repro - Build # 3270 - Failure

[Apache Jenkins Server]

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

[...truncated 29 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.1/34/consoleText

[...truncated 23 lines...]
raise RuntimeError('ERROR: fetching %s : %s' % (url, e))
RuntimeError: ERROR: fetching 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.1/34/consoleText : 
HTTP Error 404: 
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-NightlyTests-7.7 - Build # 13 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.7/13/

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest

Error Message:
ObjectTracker found 6 object(s) that were not released!!! [MMapDirectory, 
MMapDirectory, InternalHttpClient, SolrCore, MMapDirectory, MMapDirectory] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:359)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:738)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:967)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:874)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1187)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:699)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:503)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:346) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:425) 
 at org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:237) 
 at 
org.apache.solr.cloud.RecoveryStrategy.doReplicateOnlyRecovery(RecoveryStrategy.java:382)
  at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:328)  
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:307)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.http.impl.client.InternalHttpClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:321)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:330)
  at 
org.apache.solr.handler.IndexFetcher.createHttpClient(IndexFetcher.java:225)  
at org.apache.solr.handler.IndexFetcher.(IndexFetcher.java:267)  at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:421) 
 at org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:237) 
 at 
org.apache.solr.cloud.RecoveryStrategy.doReplicateOnlyRecovery(RecoveryStrategy.java:382)
  at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:328)  
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:307)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1054)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:874)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1187)
  at 

[GitHub] [lucene-solr] janhoy opened a new pull request #679: LUCENE-8802: buildAndPushRelease --logfile arg

[GitBox]

janhoy opened a new pull request #679: LUCENE-8802: buildAndPushRelease 
--logfile arg
URL: https://github.com/apache/lucene-solr/pull/679
 
 
   


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


With regards,
Apache Git Services

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

[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 103 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/103/

All tests passed

Build Log:
[...truncated 65701 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 2531 links (2070 relative) to 3359 anchors in 253 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/solr/build/solr-ref-guide/bare-bones-html/

-documentation-lint:
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/lucene/build/jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for malformed docs...
 [exec] 
 [exec] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/solr/build/docs/solr-solrj/overview-summary.html
 [exec]   missing description: org.noggit
 [exec] 
 [exec] Missing javadocs were found!

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/build.xml:643:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/build.xml:101:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/solr/build.xml:660:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/solr/build.xml:676:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/lucene/common-build.xml:2530:
 exec returned: 1

Total time: 112 minutes 11 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Created] (LUCENE-8802) buildAndPushRelease --logfile arg

[JIRA]

Jan Høydahl created LUCENE-8802:
---

 Summary: buildAndPushRelease --logfile arg
 Key: LUCENE-8802
 URL: https://issues.apache.org/jira/browse/LUCENE-8802
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/build
Reporter: Jan Høydahl
Assignee: Jan Høydahl


Add possibility for custom log file destination

Also fixes a missing import causing wrong error msg at timeout exception
{code:java}
from subprocess import TimeoutExpired
{code}
 



--
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-13-ea+shipilev-fastdebug) - Build # 24092 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24092/
Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic

Error Message:
{} expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: {} expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([78D5F5126CA24AEA:D32FE807B37ECCC4]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic(SolrRrdBackendFactoryTest.java:94)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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:830)




Build Log:
[...truncated 14747 lines...]
   [junit4] Suite: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-11872) Refactor test infra to work with a managed SolrClient; ditch TestHarness

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11872:
---

bq.what some "real" converted tests would actually look like 

an example 
[here|https://github.com/apache/lucene-solr/blob/9d7c1923e4b30dc1f04a56986628944c0a2b6a6e/solr/solrj/src/test/org/apache/solr/client/solrj/SolrExampleTests.java#L309]

This test uses standard solrj apis and use a "json path syntax" to validate the 
response. It currently works for both JSON/javabin. I'm not saying it is 
perfect , but it is one example that came to my mind

> Refactor test infra to work with a managed SolrClient; ditch TestHarness
> 
>
> Key: SOLR-11872
> URL: https://issues.apache.org/jira/browse/SOLR-11872
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: David Smiley
>Priority: Major
>
> This is a proposal to substantially refactor SolrTestCaseJ4 and some of its 
> intermediate subclasses in the hierarchy.  _In essence, I envision that tests 
> should work with a SolrClient typed "solrClient" field managed by the test 
> infrastructure._ With only a few lines of code, a test should be able to pick 
> between an instance based on EmbeddedSolrServer (lighter tests), 
> HttpSolrClient (tests HTTP/Jetty behavior directly or indirectly), SolrCloud, 
> and perhaps a special one for our distributed search tests. STCJ4 would 
> refactor its methods to use the solrClient field _instead of TestHarness_. 
> TestHarness would disappear as-such; bits of its existing code would migrate 
> elsewhere, such as to manage an EmbeddedSolrServer for testing.
> I think we can do a transition like this in stages and furthermore minimally 
> affecting most tests by adding some deprecated shims. Perhaps STCJ4 should 
> _become_ the deprecated shim so that users can still use it during 7.x and to 
> help us with the transition internally too. More specifically, we'd add a new 
> superclass to STCJ4 that is the future – "SolrTestCase".
> Additionally, there are a bunch of methods on SolrTestCaseJ4 that I question 
> the design of, especially ones that return XML strings like {{delI}} 
> (generates a delete-by-id XML string) and {{adoc}}. Perhaps that used to be a 
> fine idea before there was a convenient SolrClient API but we've got one now 
> and a test shouldn't be building XML unless it's trying to test exactly that.
> For consulting work I once developed a JUnit4 {{TestRule}} managing a 
> SolrClient that is declared in a test with an annotation of {{@ClassRule}}. I 
> had a variation for SolrCloud and EmbeddedSolrServer that was easy for a test 
> to choose. Since TestRule is an interface, I was able to make a special 
> delegating SolrClient subclass that implements TestRule. This isn't essential 
> but makes use of it easier since otherwise you'd be forced to call something 
> like getSolrClient(). We could go the TestRule route here, which I prefer 
> (with or without having it subclass SolrClient), or we could alternatively do 
> TestCase subclassing to manage the lifecycle.
> Initially I'm just looking for agreement and refinement of the approach. 
> After that, sub-tasks ought to be added. I won't have time to work on this 
> for some time.



--
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-master - Build # 1849 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1849/

2 tests failed.
FAILED:  org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([35554349D37B0989:4EEFD7C76441959]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:941)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:901)
at 
org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts(SpellCheckCollatorTest.java:569)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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:834)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//lst[@name='spellcheck']/lst[@name='collations']/lst[@name='collation']/long[@name='hits'
 and 3 <= . and . <= 13]
xml response was: 

041918everyotherteststop:everyother14everyother


request 

[jira] [Commented] (SOLR-13350) Explore collector managers for multi-threaded search

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-13350:
-

I just want to point out that this idea was explored by Etsy who presented 
their findings in a Lucene Revolution presentation years ago: 
[https://www.slideshare.net/lucidworks/searchtime-parallelism-presented-by-shikhar-bhushan-etsy-41862845]
  One issue that I remember is that there is difficulty in concurrently using a 
DocSetCollector (subsequently used for filter cache and stats/facets) which was 
not designed for concurrency.  You can see the slides cover that.

> Explore collector managers for multi-threaded search
> 
>
> Key: SOLR-13350
> URL: https://issues.apache.org/jira/browse/SOLR-13350
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-13350.patch, SOLR-13350.patch, SOLR-13350.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> AFAICT, SolrIndexSearcher can be used only to search all the segments of an 
> index in series. However, using CollectorManagers, segments can be searched 
> concurrently and result in reduced latency. Opening this issue to explore the 
> effectiveness of using CollectorManagers in SolrIndexSearcher from latency 
> and throughput perspective.



--
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-11872) Refactor test infra to work with a managed SolrClient; ditch TestHarness

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11872:
---

Is there a way to split this into smaller tasks ? 

Ideally, we should write everything against an API. I mean no direct xml, json 
etc. That means most of the tests will need to be rewritten. This is a huge 
undertaking. We will have to collaborate and divide the work. I'll be happy to 
pitch in. 


> Refactor test infra to work with a managed SolrClient; ditch TestHarness
> 
>
> Key: SOLR-11872
> URL: https://issues.apache.org/jira/browse/SOLR-11872
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: David Smiley
>Priority: Major
>
> This is a proposal to substantially refactor SolrTestCaseJ4 and some of its 
> intermediate subclasses in the hierarchy.  _In essence, I envision that tests 
> should work with a SolrClient typed "solrClient" field managed by the test 
> infrastructure._ With only a few lines of code, a test should be able to pick 
> between an instance based on EmbeddedSolrServer (lighter tests), 
> HttpSolrClient (tests HTTP/Jetty behavior directly or indirectly), SolrCloud, 
> and perhaps a special one for our distributed search tests. STCJ4 would 
> refactor its methods to use the solrClient field _instead of TestHarness_. 
> TestHarness would disappear as-such; bits of its existing code would migrate 
> elsewhere, such as to manage an EmbeddedSolrServer for testing.
> I think we can do a transition like this in stages and furthermore minimally 
> affecting most tests by adding some deprecated shims. Perhaps STCJ4 should 
> _become_ the deprecated shim so that users can still use it during 7.x and to 
> help us with the transition internally too. More specifically, we'd add a new 
> superclass to STCJ4 that is the future – "SolrTestCase".
> Additionally, there are a bunch of methods on SolrTestCaseJ4 that I question 
> the design of, especially ones that return XML strings like {{delI}} 
> (generates a delete-by-id XML string) and {{adoc}}. Perhaps that used to be a 
> fine idea before there was a convenient SolrClient API but we've got one now 
> and a test shouldn't be building XML unless it's trying to test exactly that.
> For consulting work I once developed a JUnit4 {{TestRule}} managing a 
> SolrClient that is declared in a test with an annotation of {{@ClassRule}}. I 
> had a variation for SolrCloud and EmbeddedSolrServer that was easy for a test 
> to choose. Since TestRule is an interface, I was able to make a special 
> delegating SolrClient subclass that implements TestRule. This isn't essential 
> but makes use of it easier since otherwise you'd be forced to call something 
> like getSolrClient(). We could go the TestRule route here, which I prefer 
> (with or without having it subclass SolrClient), or we could alternatively do 
> TestCase subclassing to manage the lifecycle.
> Initially I'm just looking for agreement and refinement of the approach. 
> After that, sub-tasks ought to be added. I won't have time to work on this 
> for some time.



--
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-8.x-Linux (64bit/jdk-11.0.2) - Build # 570 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/570/
Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 59003 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:634: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:507: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:494: Source checkout is 
dirty (unversioned/missing files) after running tests!!! Offending files:
* solr/licenses/noggit-0.8.jar.sha1

Total time: 74 minutes 20 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Closed] (SOLR-13172) Deprecate MoreLikeTHisHandler

[David Smiley (JIRA)]

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

David Smiley closed SOLR-13172.
---

> Deprecate MoreLikeTHisHandler
> -
>
> Key: SOLR-13172
> URL: https://issues.apache.org/jira/browse/SOLR-13172
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: MoreLikeThis
>Reporter: Alessandro Benedetti
>Priority: Major
>
> Following the discussions with [~dsmi...@mac.com]
> Currently the Lucene More Like This functionality is offered in Apache Solr 
> through :
>  * More Like This Handler
>  * More Like This Component
>  * More Like This Query Parser
> The query parser is the most flexible approach and it is well supported, it 
> is a good candidate to become the main entry point if a user wnat the MLT 
> functionality.
> The More Like This component is quite coupled with the others but it has a 
> sense and offers slightly different features from the query parser ( *Using 
> MoreLikeThis as a search component returns similar documents for each 
> document in the response set.*)
> So the proposal here is to deprecate and remove the More Like This Handler, 
> to ease the maintenance  of the functionality and to simplify the way new 
> users approach 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] [Assigned] (SOLR-12304) Interesting Terms parameter is ignored by MLT Component

[David Smiley (JIRA)]

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

David Smiley reassigned SOLR-12304:
---

Assignee: David Smiley

> Interesting Terms parameter is ignored by MLT Component
> ---
>
> Key: SOLR-12304
> URL: https://issues.apache.org/jira/browse/SOLR-12304
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: MoreLikeThis
>Affects Versions: 7.2
>Reporter: Alessandro Benedetti
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12304.patch, SOLR-12304.patch, SOLR-12304.patch, 
> SOLR-12304.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the More Like This component just ignores the mlt.InterestingTerms 
> parameter ( which is usable by the MoreLikeThisHandler).
> Scope of this issue is to fix the bug and add related tests ( which will 
> succeed after the fix )
> *N.B.* MoreLikeThisComponent and MoreLikeThisHandler are very coupled and the 
> tests for the MoreLikeThisHandler are intersecting the MoreLikeThisComponent 
> ones .
>  It is out of scope for this issue any consideration or refactor of that.
>  Other issues will follow.
> *N.B.* out of scope for this issue is the distributed case, which is much 
> more complicated and requires much deeper investigations



--
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-13172) Deprecate MoreLikeTHisHandler

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-13172.
-
Resolution: Won't Fix

> Deprecate MoreLikeTHisHandler
> -
>
> Key: SOLR-13172
> URL: https://issues.apache.org/jira/browse/SOLR-13172
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: MoreLikeThis
>Reporter: Alessandro Benedetti
>Priority: Major
>
> Following the discussions with [~dsmi...@mac.com]
> Currently the Lucene More Like This functionality is offered in Apache Solr 
> through :
>  * More Like This Handler
>  * More Like This Component
>  * More Like This Query Parser
> The query parser is the most flexible approach and it is well supported, it 
> is a good candidate to become the main entry point if a user wnat the MLT 
> functionality.
> The More Like This component is quite coupled with the others but it has a 
> sense and offers slightly different features from the query parser ( *Using 
> MoreLikeThis as a search component returns similar documents for each 
> document in the response set.*)
> So the proposal here is to deprecate and remove the More Like This Handler, 
> to ease the maintenance  of the functionality and to simplify the way new 
> users approach 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] [Commented] (SOLR-13473) Ensure that the tests use JSON,javabin to update docs

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-13473:
-

This issue is one small piece of my plan in SOLR-11872 to substantially 
refactor our testing infrastructure (code).  I just want to link it.  Doing 
SOLR-11872 is one of my goals this year.  Before we have tests with a 
SolrClient, it's hard to do this issue since the mechanism of update is 
different.  Once we have that, then we can randomize the underlying update to 
use JavaBin/JSON/XML.

> Ensure that the tests use JSON,javabin to update docs
> -
>
> Key: SOLR-13473
> URL: https://issues.apache.org/jira/browse/SOLR-13473
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> {{SolrTestCaseJ4#assertU}} sends documents as XML. XML is a very uncommon 
> update format .
> We should change it to use JSON/javabin 



--
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-13468) autoscaling/suggestions should be able to give suggestions from payload

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13468:


Commit 2b329128dd45a546b15ae7d1535cbdf1489db475 in lucene-solr's branch 
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2b32912 ]

SOLR-13468: remove license files


> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling 
> configuration sent as a payload . This is helpful in debugging the system or 
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}



--
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-13473) Ensure that the tests use JSON,javabin to update docs

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-13473:
---

bq. Could we randomize it instead? 

yes, my bad. It should be randomized and there should be a command line option 
to force one of the 3 formats too

> Ensure that the tests use JSON,javabin to update docs
> -
>
> Key: SOLR-13473
> URL: https://issues.apache.org/jira/browse/SOLR-13473
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> {{SolrTestCaseJ4#assertU}} sends documents as XML. XML is a very uncommon 
> update format .
> We should change it to use JSON/javabin 



--
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-13468) autoscaling/suggestions should be able to give suggestions from payload

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13468:


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

SOLR-13468: remove license files


> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling 
> configuration sent as a payload . This is helpful in debugging the system or 
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}



--
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-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11127:
-

You've been working on some cool and useful issues [~ab] – kudos!

I want to mention a couple suggestions to improve this feature in the future:
 * Making the source collection read-only might be inconvenient or infeasible 
for some apps.  As an option, a best-effort attempt would be useful.  Even if 
some changes don't make it, the client may already have a means of detecting 
data that needs to be resent, such as using a strategy involving looking at the 
highest timestamp. Or it may simply not matter, like for an experiment on the 
target.
 * IMO {{batchSize}} would have been a more appropriate name for {{rows}} 
param, which as it stands appears to be something that limits the reindexing to 
just this number of documents. After all, you used the same param name that we 
are all intimately familiar with for /select uses. I see this use of "rows" was 
in turn used by topic() but that's the same issue there. Ah well; many users 
won't touch this any way.

Also I suggest re-titling this issue to reflect your commit message – 
"REINDEXCOLLECTION command for re-indexing of existing collections.", not the 
original goal.

> Add a Collections API command to migrate the .system collection schema from 
> Trie-based (pre-7.0) to Points-based (7.0+)
> ---
>
> Key: SOLR-11127
> URL: https://issues.apache.org/jira/browse/SOLR-11127
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki 
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-11127.patch, SOLR-11127.patch, SOLR-11127.patch, 
> SOLR-11127.patch
>
>
> SOLR-9 will switch the Trie fieldtypes in the .system collection's schema 
> to Points.
> Users with pre-7.0 .system collections will no longer be able to use them 
> once Trie fields have been removed (8.0).
> Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to 
> automatically convert a Trie-based .system collection to a Points-based one.



--
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-13475) Nullpointer-Exception when querying collection through collection alias

[JIRA]

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

Jörn Franke commented on SOLR-13475:


thanks a lot for the quick fix. I have at the moment not a machine to build 
Solr, it will take me some days due to other tasks.

> Nullpointer-Exception when querying collection through collection alias
> ---
>
> Key: SOLR-13475
> URL: https://issues.apache.org/jira/browse/SOLR-13475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 8.1
>Reporter: Jörn Franke
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13475.patch
>
>
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
> collection aliases, but I am not 100% sure it is due to the upgrade.
>  
> Situation:
> I have a collection called c_testcollection. 
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue to query the collection through its alias 
> "testcollection", e.g 
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> [http://localhost:8983/solr/c_testcollection/select?q=test]
> When I do a query on testcollection then I receive the stacktrace below
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> Additionally I observe a strange behavior in the admin ui. When I try to 
> create an alias (e.g. new) for a new collection (e.g. c_new) then it creates 
> two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove 
> the alias from c_new to c_new then I get the same error. Is this desired 
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to filter 
> them out in my application when retrieving all aliases.
> Is there a related issue.
>  
> Here the stacktrace:
> {
>   "error":{
>     "trace":"java.lang.NullPointerException\n\tat 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>  
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>  org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  

[jira] [Commented] (SOLR-13437) fork noggit code to Solr

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-13437:
---

How come {{ant precommit}} it is passing for me?

> fork noggit code to Solr
> 
>
> Key: SOLR-13437
> URL: https://issues.apache.org/jira/browse/SOLR-13437
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> We rely on noggit for all our JSON encoding/decoding needs.The main project 
> is not actively maintained . We cannot easily switch to another parser 
> because it may cause backward incompatibility and we have advertised the 
> ability to use flexible JSON and we also use noggit internally in many classes



--
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: Concerned about Solr's V2 API synchronized with V1

[Jan Høydahl]

+1

Perhaps it’s possible to use forbiddenapis to block new test classes explicitly 
calling v1 apis? (Look for “/solr/admin/.*”)? And of course make sure that 
SolrJ commands map to v2...

Jan Høydahl

> 16. mai 2019 kl. 19:33 skrev David Smiley :
> 
> I'm concerned about Solr's V2 API and the maintenance burden of attempting to 
> maintain consistency with V1.  For example upon looking through the release 
> notes and seeing a new exciting REINDEXCOLLECTION command (a V1 reference), I 
> see no corresponding adjustments in V2 -- 
> lucene-solr/solr/solrj/src/resources/apispec/*   It's so easy for this to 
> fall out of sync.  When working on a feature affecting admin API stuff I need 
> to somehow just remember/know and then ask myself if I want to test a new 
> feature with just one API or both. Ugh.  Additionally, the vast majority of 
> our documentation is in V1, and our help in solr-user and elsewhere often 
> uses a one-liner URL to the V1 API as well.
> 
> As if Solr needed more maintenance challenges than it has already (e.g. 
> tests).   :-(
> 
> I mainly want to point out this problem right now to see if others also see 
> the problem and if anyone else has thought about it.  While working on Time 
> Routed Aliases, I saw it but didn't call it out.  I thought maybe somehow our 
> implementation of the admin functionality could be done differently so as to 
> nearly require a V2 adjustment, and thus we don't forget.  For example if the 
> V2 API was basically primary, and if it had metadata that described how a 
> virtual V1 API could work based off metadata in the V2 apispec there that 
> does mapping.  In this way, everything would work in V2 and V1 by default, or 
> at least the majority of the time.  V2 requires more information than V1, so 
> if we continue to have V1 primary (i.e. do nothing), V2 will always be 
> falling behind.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11) - Build # 24091 - Still Failing!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 62079 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj311801445
 [ecj-lint] Compiling 1273 source files to /tmp/ecj311801445
 [ecj-lint] Processing annotations
 [ecj-lint] Annotations processed
 [ecj-lint] Processing annotations
 [ecj-lint] No elements to process
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
 (at line 219)
 [ecj-lint] return (NamedList) new 
JavaBinCodec(resolver).unmarshal(in);
 [ecj-lint]^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/autoscaling/AutoScalingHandler.java
 (at line 74)
 [ecj-lint] import static org.apache.solr.common.util.Utils.fromJSON;
 [ecj-lint]   ^^
 [ecj-lint] The import org.apache.solr.common.util.Utils.fromJSON is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 788)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 4. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 794)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 5. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/handler/admin/SegmentsInfoRequestHandler.java
 (at line 215)
 [ecj-lint] leafReader = ((FilterLeafReader)leafReader).getDelegate();
 [ecj-lint] ^
 [ecj-lint] Resource leak: 'leafReader' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 6. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
 (at line 142)
 [ecj-lint] return new JavaBinCodec(null, 
stringCache).setReadStringAsCharSeq(true);
 [ecj-lint]^^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 7. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java
 (at line 137)
 [ecj-lint] new JavaBinCodec() {
 [ecj-lint]   SolrParams params;
 [ecj-lint]   AddUpdateCommand addCmd = null;
 [ecj-lint] 
 [ecj-lint]   @Override
 [ecj-lint]   public List readIterator(DataInputInputStream fis) 
throws IOException {
 [ecj-lint] while (true) {
 [ecj-lint]   Object o = readVal(fis);
 [ecj-lint]   if (o == END_OBJ) break;
 [ecj-lint]   if (o instanceof NamedList) {
 [ecj-lint] params = ((NamedList) o).toSolrParams();
 [ecj-lint]   } else {
 [ecj-lint] try {
 [ecj-lint]   if (o instanceof byte[]) {
 [ecj-lint] if (params != null) req.setParams(params);
 [ecj-lint] byte[] buf = (byte[]) o;
 [ecj-lint] contentStreamLoader.load(req, rsp, new 
ContentStreamBase.ByteArrayStream(buf, null), processor);
 [ecj-lint]   } else {
 [ecj-lint] throw new RuntimeException("unsupported type ");
 [ecj-lint]   }
 [ecj-lint] } catch (Exception e) {
 [ecj-lint]   throw new RuntimeException(e);
 [ecj-lint] } finally {
 [ecj-lint]   params = null;
 [ecj-lint]   req.setParams(old);
 [ecj-lint] }
 [ecj-lint]   }
 [ecj-lint] }
 [ecj-lint] return Collections.emptyList();
 [ecj-lint]   }
 [ecj-lint] 
 [ecj-lint] }.unmarshal(in);
 

[jira] [Commented] (SOLR-13437) fork noggit code to Solr

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13437:
--

You changes caused {{ant precommit}} to fail:
{code}
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24090/
Java: 64bit/jdk-12 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 58603 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:634: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:507: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:494: Source checkout 
is dirty (unversioned/missing files) after running tests!!! Offending files:
* solr/licenses/noggit-0.8.jar.sha1
{code}

> fork noggit code to Solr
> 
>
> Key: SOLR-13437
> URL: https://issues.apache.org/jira/browse/SOLR-13437
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> We rely on noggit for all our JSON encoding/decoding needs.The main project 
> is not actively maintained . We cannot easily switch to another parser 
> because it may cause backward incompatibility and we have advertised the 
> ability to use flexible JSON and we also use noggit internally in many classes



--
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-13468) autoscaling/suggestions should be able to give suggestions from payload

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13468:


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

SOLR-13468: unused imports


> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling 
> configuration sent as a payload . This is helpful in debugging the system or 
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}



--
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-13468) autoscaling/suggestions should be able to give suggestions from payload

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13468:


Commit 92451cf99ca4b864e5e5a10ac5ffb39a67c0cfa3 in lucene-solr's branch 
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=92451cf ]

SOLR-13468: unused imports


> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling 
> configuration sent as a payload . This is helpful in debugging the system or 
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}



--
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] [Reopened] (SOLR-13468) autoscaling/suggestions should be able to give suggestions from payload

[Hoss Man (JIRA)]

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

Hoss Man reopened SOLR-13468:
-

[~noble.paul] - this broke precommit (and has been failing every jenkins build 
for the psat ~21 hours)

{noformat}
 [ecj-lint] 2. ERROR in 
/home/hossman/lucene/dev/solr/core/src/java/org/apache/solr/cloud/autoscaling/AutoScalingHandler.java
 (at line 74)
 [ecj-lint] import static org.apache.solr.common.util.Utils.fromJSON;
 [ecj-lint]   ^^
 [ecj-lint] The import org.apache.solr.common.util.Utils.fromJSON is never used
{noformat}

> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling 
> configuration sent as a payload . This is helpful in debugging the system or 
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}



--
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-13476) Tests should verify output in json/javabin formats as well

[Noble Paul (JIRA)]

Noble Paul created SOLR-13476:
-

 Summary: Tests should verify output in json/javabin formats as well
 Key: SOLR-13476
 URL: https://issues.apache.org/jira/browse/SOLR-13476
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul


A lot of our tests are written to get the responses in XML. the problem is we 
search for XML strings , XPATH. This will need a lot of tests to be rewritten.




--
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-13473) Ensure that the tests use JSON,javabin to update docs

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-13473:
---

bq. And doing anything similar for queries where we pass in XPath strings I'll 
leave for later

Yes, ideally that too. I'll anyway open a ticket

> Ensure that the tests use JSON,javabin to update docs
> -
>
> Key: SOLR-13473
> URL: https://issues.apache.org/jira/browse/SOLR-13473
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> {{SolrTestCaseJ4#assertU}} sends documents as XML. XML is a very uncommon 
> update format .
> We should change it to use JSON/javabin 



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

Concerned about Solr's V2 API synchronized with V1

[David Smiley]

I'm concerned about Solr's V2 API and the maintenance burden of attempting
to maintain consistency with V1.  For example upon looking through the
release notes and seeing a new exciting REINDEXCOLLECTION command (a V1
reference), I see no corresponding adjustments in V2 --
lucene-solr/solr/solrj/src/resources/apispec/*   It's so easy for this to
fall out of sync.  When working on a feature affecting admin API stuff I
need to somehow just remember/know and then ask myself if I want to test a
new feature with just one API or both. Ugh.  Additionally, the vast
majority of our documentation is in V1, and our help in solr-user and
elsewhere often uses a one-liner URL to the V1 API as well.

As if Solr needed more maintenance challenges than it has already (e.g.
tests).   :-(

I mainly want to point out this problem right now to see if others also see
the problem and if anyone else has thought about it.  While working on Time
Routed Aliases, I saw it but didn't call it out.  I thought maybe somehow
our implementation of the admin functionality could be done differently so
as to nearly require a V2 adjustment, and thus we don't forget.  For
example if the V2 API was basically primary, and if it had metadata that
described how a virtual V1 API could work based off metadata in the V2
apispec there that does mapping.  In this way, everything would work in V2
and V1 by default, or at least the majority of the time.  V2 requires more
information than V1, so if we continue to have V1 primary (i.e. do
nothing), V2 will always be falling behind.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

ReleaseWizard tool

[Jan Høydahl]

Just a heads-up that as part of my releasing 7.7.2 effort I'm also hacking on
a releaseWizard script to replace the ReleaseTodo wiki page. It will act as a
checklist where you see tasks that needs to be done (different for 
major/minor/bug)
and mark those completed. It will also run all the commands for you and preserve
the logs, generate e-mail templates with all versions, dates etc in place, 
handle
voting rules and counting etc. It will also generate an asciidoc + HTML page 
that 
gives a nice overview of the whole thing :)

Here's a teaser:

https://asciinema.org/a/246656

  ┌─┐
  │ │
  │  Releasing Lucene/Solr 7.7.2 RC1│
  │ │
  │  Please complete the below checklist (Complete: 4/11)   │
  │ │
  │ │
  │1 - ✓ Prerequisites (3/3)│
  │2 - ✓ Work with the community to decide when and how etc (1/1)   │
  │3 - ✓ Create branch (if needed) and update versions (4/4)│
  │4 - ✓ Add new versions to JIRA (2/2) │
  │5 - Build the release artifacts (2/3)│
  │6 - Hold the vote and sum up the results (0/2)   │
  │7 - Publish the release artifacts (0/1)  │
  │8 - Update the website (0/1) │
  │9 - Update the DOAP file (0/1)   │
  │   10 - Announce the release (0/1)   │
  │   11 - Tasks to do after release (0/1)  │
  │   12 - Exit │
  │ │
  │ │
  └─┘

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

[jira] [Resolved] (SOLR-13468) autoscaling/suggestions should be able to give suggestions from payload

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-13468.
---
   Resolution: Fixed
Fix Version/s: 8.2

> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling 
> configuration sent as a payload . This is helpful in debugging the system or 
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}



--
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: Lucene/Solr 7.7.2

[Andrzej Białecki]

However, changes from all these commits have been already incorporated into 
branch_7_7 in these commits:

fd2851a8d80e81835b45c47ac183282831f30764
2de07e64a959ee380b8bb0159c6193055c969492


> On 16 May 2019, at 18:50, Jan Høydahl  wrote:
> 
> I merged cde00b9a84f3d57252d34daaa77f2b56cf9802cb.
> 
> These commits are not in branch_7_7 either:
> 
> 77cf083e1417e4ac910f06626ae3cb6c3c77a32b Fix PeerSyncTest and 
> TestInPlaceUpdatesDistrib failures Ishan Chattopadhyaya 2019-05-02 23:06
> d9d3c89e3e50f8acee4ad07fff8cd448e2b9b585 DistributedUpdateProcessorTest 
> assumeWorkingMockito() David Smiley* 2019-05-01 06:30
> 74bc993b965c9f51e9a5113c8a6d02b45a423a4a Test should use ExecutorUtil David 
> Smiley 2019-05-01 20:30
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
>> 16. mai 2019 kl. 17:54 skrev Andrzej Białecki 
>> mailto:andrzej.biale...@lucidworks.com>>:
>> 
>> Bulk of SOLR-12833 (including recent changes) should already be there 
>> because it was committed to branch_7_7, with the exception of 
>> cde00b9a84f3d57252d34daaa77f2b56cf9802cb which still needs to be merged to 
>> 7_7 and now to 7_7_2.
>> 
>>> On 16 May 2019, at 17:38, Jan Høydahl >> > wrote:
>>> 
>>> So now backCompat indices for 6.6.6 are pushed, smoketester should be happy.
>>> 
>>> I have also backported these JIRAs, ready to push to branch_7_7, currently 
>>> running tests:
>>> 
>>> SOLR-13229:  Cleanup replicasMetTragicEvent after all exceptions
>>> SOLR-13352:  Remove risk of deadlock/threadleak when shutting down an 
>>> Overseer(TriggerThread)
>>> SOLR-13366:  Clarify 'Invalid stage name' warning logging in 
>>> AutoScalingConfig
>>> SOLR-13386:  OverseerTaskQueue#remove should not throw an exception when no 
>>> node exists after... 
>>> SOLR-13398:  Move log "Processing SSL Credential Provider chain" from INFO 
>>> to DEBUG to prevent...
>>> LUCENE-8720: fix int overflow in NameIntCacheLRU
>>> SOLR-13252:  Fix an NPE when setting a "policy" property for an existing 
>>> collection.
>>> SOLR-13254:  Correct message that is logged in solrj's ConnectionManager 
>>> when an exception…
>>> 
>>> I see no BLOCKERS, and the only JIRA I have on my list for potential 
>>> backport now is
>>> SOLR-12833:  Use timed-out lock in DistributedUpdateProcessor
>>> 
>>> Ishan, Hoss, Andrzej, Smiley, you recently worked with it, what is your 
>>> evaluation of whether it should go in 7.7.2?
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com 
>>> 
 14. mai 2019 kl. 15:38 skrev Ishan Chattopadhyaya 
 mailto:ichattopadhy...@gmail.com>>:
 
> I would like to backport SOLR-13410, as without this the ADDROLE of
> "overseer" is effectively broken. Please let me know if that is fine.
 
 Just backported this. Hope there's still some time for a Jenkins run or 
 two.
 
 On Tue, May 14, 2019 at 2:48 PM Jan Høydahl >>> > wrote:
> 
> Jenkins jobs for 7_7 were enabled today. Will build the first RC once we 
> the results of the first few runs.
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
> 10. mai 2019 kl. 21:16 skrev Kevin Risden  >:
> 
> Finished backport of SOLR-13112 for Jackson 2.9.8
> 
> Kevin Risden
> 
> 
> On Thu, May 9, 2019 at 6:57 PM Jan Høydahl  > wrote:
>> 
>> Looks safe to backport, go ahead!
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com 
>> 
>> 9. mai 2019 kl. 23:07 skrev Cassandra Targett > >:
>> 
>> Someone brought https://issues.apache.org/jira/browse/SOLR-13112 
>>  to my attention 
>> today, which upgraded the Jackson dependencies to 2.9.8. Would it be 
>> possible for those to be backported to branch_7_7 for inclusion in 7.7.2?
>> 
>> Cassandra
>> On May 8, 2019, 2:51 PM -0500, Jan Høydahl > >, wrote:
>> 
>> Yes please do!
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com 
>> 
>> 8. mai 2019 kl. 18:25 skrev Ishan Chattopadhyaya 
>> mailto:ichattopadhy...@gmail.com>>:
>> 
>> I would like to backport SOLR-13410, as without this the ADDROLE of
>> "overseer" is effectively broken. Please let me know if that is fine.
>> 
>> On Sat, May 4, 2019 at 2:22 AM Jan Høydahl > > wrote:
>> 
>> 
>> Sure, go ahead!
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com 

Re: 8.1.1 bug fix release

[Ishan Chattopadhyaya]

Thanks Andrzej. I recommend you get all access (Jira, wiki etc), complete
all GPG key prerequisites beforehand. I remember wasting a day on those
when I did my first release.

On Thu, 16 May, 2019, 10:24 PM Andrzej Białecki,  wrote:

> Hi,
>
> Just right after the 8.1.0 release has been published we’ve discovered a
> serious bug in the way aliases are handled in the Admin UI (and in some
> cases leading to NPE when using API). Details of the bug can be found in
> SOLR-13475.
>
> I’m volunteering to do this release, if there are no objections, and I’d
> like to create a RC early next week (I need to get up to speed on the
> release process ;) ).
>
> —
>
> Andrzej Białecki
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-12833) Use timed-out lock in DistributedUpdateProcessor

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12833:


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

Adjust wording on SOLR-12833 entry in 7.7.2 section


> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 7.7, 7.7.2, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch, threadDump.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
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: Lucene/Solr 7.7.2

[Jan Høydahl]

Andrzej you are right, the three other commits I listed are already in the 
branch, then SOLR-12833 is done. Thanks.

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

> 16. mai 2019 kl. 18:50 skrev Jan Høydahl :
> 
> I merged cde00b9a84f3d57252d34daaa77f2b56cf9802cb.
> 
> These commits are not in branch_7_7 either:
> 
> 77cf083e1417e4ac910f06626ae3cb6c3c77a32b Fix PeerSyncTest and 
> TestInPlaceUpdatesDistrib failures Ishan Chattopadhyaya 2019-05-02 23:06
> d9d3c89e3e50f8acee4ad07fff8cd448e2b9b585 DistributedUpdateProcessorTest 
> assumeWorkingMockito() David Smiley* 2019-05-01 06:30
> 74bc993b965c9f51e9a5113c8a6d02b45a423a4a Test should use ExecutorUtil David 
> Smiley 2019-05-01 20:30
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
>> 16. mai 2019 kl. 17:54 skrev Andrzej Białecki 
>> mailto:andrzej.biale...@lucidworks.com>>:
>> 
>> Bulk of SOLR-12833 (including recent changes) should already be there 
>> because it was committed to branch_7_7, with the exception of 
>> cde00b9a84f3d57252d34daaa77f2b56cf9802cb which still needs to be merged to 
>> 7_7 and now to 7_7_2.
>> 
>>> On 16 May 2019, at 17:38, Jan Høydahl >> > wrote:
>>> 
>>> So now backCompat indices for 6.6.6 are pushed, smoketester should be happy.
>>> 
>>> I have also backported these JIRAs, ready to push to branch_7_7, currently 
>>> running tests:
>>> 
>>> SOLR-13229:  Cleanup replicasMetTragicEvent after all exceptions
>>> SOLR-13352:  Remove risk of deadlock/threadleak when shutting down an 
>>> Overseer(TriggerThread)
>>> SOLR-13366:  Clarify 'Invalid stage name' warning logging in 
>>> AutoScalingConfig
>>> SOLR-13386:  OverseerTaskQueue#remove should not throw an exception when no 
>>> node exists after... 
>>> SOLR-13398:  Move log "Processing SSL Credential Provider chain" from INFO 
>>> to DEBUG to prevent...
>>> LUCENE-8720: fix int overflow in NameIntCacheLRU
>>> SOLR-13252:  Fix an NPE when setting a "policy" property for an existing 
>>> collection.
>>> SOLR-13254:  Correct message that is logged in solrj's ConnectionManager 
>>> when an exception…
>>> 
>>> I see no BLOCKERS, and the only JIRA I have on my list for potential 
>>> backport now is
>>> SOLR-12833:  Use timed-out lock in DistributedUpdateProcessor
>>> 
>>> Ishan, Hoss, Andrzej, Smiley, you recently worked with it, what is your 
>>> evaluation of whether it should go in 7.7.2?
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com 
>>> 
 14. mai 2019 kl. 15:38 skrev Ishan Chattopadhyaya 
 mailto:ichattopadhy...@gmail.com>>:
 
> I would like to backport SOLR-13410, as without this the ADDROLE of
> "overseer" is effectively broken. Please let me know if that is fine.
 
 Just backported this. Hope there's still some time for a Jenkins run or 
 two.
 
 On Tue, May 14, 2019 at 2:48 PM Jan Høydahl >>> > wrote:
> 
> Jenkins jobs for 7_7 were enabled today. Will build the first RC once we 
> the results of the first few runs.
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
> 10. mai 2019 kl. 21:16 skrev Kevin Risden  >:
> 
> Finished backport of SOLR-13112 for Jackson 2.9.8
> 
> Kevin Risden
> 
> 
> On Thu, May 9, 2019 at 6:57 PM Jan Høydahl  > wrote:
>> 
>> Looks safe to backport, go ahead!
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com 
>> 
>> 9. mai 2019 kl. 23:07 skrev Cassandra Targett > >:
>> 
>> Someone brought https://issues.apache.org/jira/browse/SOLR-13112 
>>  to my attention 
>> today, which upgraded the Jackson dependencies to 2.9.8. Would it be 
>> possible for those to be backported to branch_7_7 for inclusion in 7.7.2?
>> 
>> Cassandra
>> On May 8, 2019, 2:51 PM -0500, Jan Høydahl > >, wrote:
>> 
>> Yes please do!
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com 
>> 
>> 8. mai 2019 kl. 18:25 skrev Ishan Chattopadhyaya 
>> mailto:ichattopadhy...@gmail.com>>:
>> 
>> I would like to backport SOLR-13410, as without this the ADDROLE of
>> "overseer" is effectively broken. Please let me know if that is fine.
>> 
>> On Sat, May 4, 2019 at 2:22 AM Jan Høydahl > > wrote:
>> 
>> 
>> Sure, go ahead!
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com 

[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-11.0.2) - Build # 569 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/569/
Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 59007 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:634: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:507: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:494: Source checkout is 
dirty (unversioned/missing files) after running tests!!! Offending files:
* solr/licenses/noggit-0.8.jar.sha1

Total time: 71 minutes 51 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Updated] (SOLR-12833) Use timed-out lock in DistributedUpdateProcessor

[JIRA]

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

Jan Høydahl updated SOLR-12833:
---
Fix Version/s: 7.7.2

> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 7.7, 7.7.2, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch, threadDump.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
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: Lucene/Solr 7.7.2

[Jan Høydahl]

I merged cde00b9a84f3d57252d34daaa77f2b56cf9802cb.

These commits are not in branch_7_7 either:

77cf083e1417e4ac910f06626ae3cb6c3c77a32b Fix PeerSyncTest and 
TestInPlaceUpdatesDistrib failures Ishan Chattopadhyaya 2019-05-02 23:06
d9d3c89e3e50f8acee4ad07fff8cd448e2b9b585 DistributedUpdateProcessorTest 
assumeWorkingMockito() David Smiley* 2019-05-01 06:30
74bc993b965c9f51e9a5113c8a6d02b45a423a4a Test should use ExecutorUtil David 
Smiley 2019-05-01 20:30

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

> 16. mai 2019 kl. 17:54 skrev Andrzej Białecki 
> :
> 
> Bulk of SOLR-12833 (including recent changes) should already be there because 
> it was committed to branch_7_7, with the exception of 
> cde00b9a84f3d57252d34daaa77f2b56cf9802cb which still needs to be merged to 
> 7_7 and now to 7_7_2.
> 
>> On 16 May 2019, at 17:38, Jan Høydahl > > wrote:
>> 
>> So now backCompat indices for 6.6.6 are pushed, smoketester should be happy.
>> 
>> I have also backported these JIRAs, ready to push to branch_7_7, currently 
>> running tests:
>> 
>> SOLR-13229:  Cleanup replicasMetTragicEvent after all exceptions
>> SOLR-13352:  Remove risk of deadlock/threadleak when shutting down an 
>> Overseer(TriggerThread)
>> SOLR-13366:  Clarify 'Invalid stage name' warning logging in 
>> AutoScalingConfig
>> SOLR-13386:  OverseerTaskQueue#remove should not throw an exception when no 
>> node exists after... 
>> SOLR-13398:  Move log "Processing SSL Credential Provider chain" from INFO 
>> to DEBUG to prevent...
>> LUCENE-8720: fix int overflow in NameIntCacheLRU
>> SOLR-13252:  Fix an NPE when setting a "policy" property for an existing 
>> collection.
>> SOLR-13254:  Correct message that is logged in solrj's ConnectionManager 
>> when an exception…
>> 
>> I see no BLOCKERS, and the only JIRA I have on my list for potential 
>> backport now is
>> SOLR-12833:  Use timed-out lock in DistributedUpdateProcessor
>> 
>> Ishan, Hoss, Andrzej, Smiley, you recently worked with it, what is your 
>> evaluation of whether it should go in 7.7.2?
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com 
>> 
>>> 14. mai 2019 kl. 15:38 skrev Ishan Chattopadhyaya 
>>> mailto:ichattopadhy...@gmail.com>>:
>>> 
 I would like to backport SOLR-13410, as without this the ADDROLE of
 "overseer" is effectively broken. Please let me know if that is fine.
>>> 
>>> Just backported this. Hope there's still some time for a Jenkins run or two.
>>> 
>>> On Tue, May 14, 2019 at 2:48 PM Jan Høydahl >> > wrote:
 
 Jenkins jobs for 7_7 were enabled today. Will build the first RC once we 
 the results of the first few runs.
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com 
 
 10. mai 2019 kl. 21:16 skrev Kevin Risden >>> >:
 
 Finished backport of SOLR-13112 for Jackson 2.9.8
 
 Kevin Risden
 
 
 On Thu, May 9, 2019 at 6:57 PM Jan Høydahl >>> > wrote:
> 
> Looks safe to backport, go ahead!
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
> 9. mai 2019 kl. 23:07 skrev Cassandra Targett  >:
> 
> Someone brought https://issues.apache.org/jira/browse/SOLR-13112 
>  to my attention today, 
> which upgraded the Jackson dependencies to 2.9.8. Would it be possible 
> for those to be backported to branch_7_7 for inclusion in 7.7.2?
> 
> Cassandra
> On May 8, 2019, 2:51 PM -0500, Jan Høydahl  >, wrote:
> 
> Yes please do!
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
> 8. mai 2019 kl. 18:25 skrev Ishan Chattopadhyaya 
> mailto:ichattopadhy...@gmail.com>>:
> 
> I would like to backport SOLR-13410, as without this the ADDROLE of
> "overseer" is effectively broken. Please let me know if that is fine.
> 
> On Sat, May 4, 2019 at 2:22 AM Jan Høydahl  > wrote:
> 
> 
> Sure, go ahead!
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
> 3. mai 2019 kl. 17:53 skrev Andrzej Białecki 
>  >:
> 
> Hi,
> 
> I would like to back-port the recent changes in the re-opened SOLR-12833, 
> since the increased memory consumption adversely affects existing 7x 
> users.
> 
> On 3 May 2019, at 10:38, Jan Høydahl  > wrote:
> 
> To not confuse two 

8.1.1 bug fix release

[Andrzej Białecki]

Hi,

Just right after the 8.1.0 release has been published we’ve discovered a 
serious bug in the way aliases are handled in the Admin UI (and in some cases 
leading to NPE when using API). Details of the bug can be found in SOLR-13475.

I’m volunteering to do this release, if there are no objections, and I’d like 
to create a RC early next week (I need to get up to speed on the release 
process ;) ).

—

Andrzej Białecki


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

[jira] [Commented] (SOLR-12833) Use timed-out lock in DistributedUpdateProcessor

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12833:


Commit 6e8fe19b3dca23b00b864e26db1e80a9b0c0dd29 in lucene-solr's branch 
refs/heads/branch_7_7 from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6e8fe19 ]

SOLR-12833: prevent NPE in DistributedUpdateProcessorTest AfterClass when 
mockito assumption fails in BeforeClass

(cherry picked from commit cde00b9a84f3d57252d34daaa77f2b56cf9802cb)


> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 7.7, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch, threadDump.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
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-13252) NPE trying to set autoscaling policy for existing collection

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13252:


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

SOLR-13252: Fix an NPE when setting a "policy" property for an existing 
collection.

(Cherry picked from 7e8a2df254b47b2b57d00a3bd75164d43c019abf)


> NPE trying to set autoscaling policy for existing collection
> 
>
> Key: SOLR-13252
> URL: https://issues.apache.org/jira/browse/SOLR-13252
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.7.2, 8.0, master (9.0)
>
> Attachments: SOLR-13252.patch
>
>
> Steps to reproduce:
> * create a collection without collection-specific policy, eg. {{test}}
> * define a collection-specific policy {{policy1}}:
> {code}
> POST http://localhost:8983/solr/admin/autoscaling
> {
> "set-policy": 
>   {
>   "policy1" :[
>   {"replica": "<2", "shard": "#EACH", "node": "#ANY"}
>   ]
>   }
> }
> {code}
> * try to modify the collection to use this policy
> {code}
> http://localhost:8983/solr/admin/collections?action=MODIFYCOLLECTION=test=policy1
> {code}
> A NullPointerException is thrown due to the previous value of the "policy" 
> property being absent:
> {code}
> 2019-02-14 18:48:17.007 ERROR 
> (OverseerThreadFactory-9-thread-5-processing-n:192.168.0.69:8983_solr) 
> [c:test   ] o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test 
> operation: modifycollection failed:java.lang.NullPointerException
> at 
> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.modifyCollection(OverseerCollectionMessageHandler.java:687)
> at 
> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:292)
> at 
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:496)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}



--
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-13229) ZkController.giveupLeadership should cleanup the replicasMetTragicEvent map after all exceptions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13229:


Commit e9f7c88097106cfcd33a8e657607d8123d5df6cd in lucene-solr's branch 
refs/heads/branch_7_7 from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e9f7c88 ]

SOLR-13229: Cleanup replicasMetTragicEvent after all exceptions

(cherry picked from commit 8ac34c2d6d105ae342985b2baaa00cc6c5bf4cfd)


> ZkController.giveupLeadership should cleanup the replicasMetTragicEvent map 
> after all exceptions
> 
>
> Key: SOLR-13229
> URL: https://issues.apache.org/jira/browse/SOLR-13229
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Fix For: 7.7.2, 8.1, master (9.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently {{ZkController.giveupLeadership}} cleans up the 
> {{replicasMetTragicEvent}} after {{Keeper|Interrupted Exceptions}}, all other 
> exceptions should also cleanup



--
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-13386) Remove race in OverseerTaskQueue#remove that can result in the Overseer causing a Zookeeper call spin spike.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13386:


Commit 1ebc103a8231ba5143f0b5fa487ff4ebd316ac1b in lucene-solr's branch 
refs/heads/branch_7_7 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1ebc103 ]

SOLR-13386: OverseerTaskQueue#remove should not throw an exception when no node 
exists after an exists check and the Overseer work loop should not allow free 
spinning the loop when it hits a KeeperException.

(Cherry picked from fe37e18d1064cc1460be67bd1ea891ad1d0d362e)


> Remove race in OverseerTaskQueue#remove that can result in the Overseer 
> causing a Zookeeper call spin spike.
> 
>
> Key: SOLR-13386
> URL: https://issues.apache.org/jira/browse/SOLR-13386
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13386.patch
>
>
> If the data call hits NoNodeException, it will throw and the Overseer work 
> queue processor will catch it and loop and repeat, which causes major zk 
> getData / NoNode call traffic or other such things.



--
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-8720) Integer overflow bug in NameIntCacheLRU.makeRoomLRU()

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8720: fix int overflow in NameIntCacheLRU

(Cherry picked from c9de94c66333fa3adfd0878ca6d38e05faff1738)


> Integer overflow bug in NameIntCacheLRU.makeRoomLRU()
> -
>
> Key: LUCENE-8720
> URL: https://issues.apache.org/jira/browse/LUCENE-8720
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.7.1
> Environment: Mac OS X 10.11.6 but this bug is not affected by the 
> environment because it is a straightforward integer overflow bug.
>Reporter: Russell A Brown
>Priority: Major
>  Labels: easyfix, patch
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: LUCENE-.patch
>
>
> The NameIntCacheLRU.makeRoomLRU() method has an integer overflow bug because 
> if maxCacheSize >= Integer.MAX_VALUE/2, 2*maxCacheSize will overflow to 
> -(2^30) and the value of n will overflow to a negative integer as well, which 
> will prevent any clearing of the cache whatsoever. Hence, performance will 
> degrade once the cache becomes full because it will be impossible to remove 
> any entries in order to add new entries to the cache.
> Moreover, comments in NameIntCacheLRU.java and LruTaxonomyWriterCache.java 
> indicate that 2/3 of the cache will be cleared, whereas in fact only 1/3 of 
> the cache is cleared. So as not to change the behavior of the 
> NameIntCacheLRU.makeRoomLRU() method, I have not changed the code to clear 
> 2/3 of the cache but instead I have changed the comments to indicate that 1/3 
> of the cache is cleared.



--
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-13398) Move log "Processing SSL Credential Provider chain" from INFO to DEBUG

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13398:


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

SOLR-13398: Move log "Processing SSL Credential Provider chain" from INFO to 
DEBUG to prevent leaking into bin/solr printout

(cherry picked from commit 03f5a5e7a1d75d6502087dbcc1ca86450875a233)


> Move log "Processing SSL Credential Provider chain" from INFO to DEBUG
> --
>
> Key: SOLR-13398
> URL: https://issues.apache.org/jira/browse/SOLR-13398
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Affects Versions: 8.0
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.7.2, 8.1
>
>
> Move log "Processing SSL Credential Provider chain" from INFO to DEBUG to 
> prevent this log line leaking into Terminal prompt when using {{bin/solr}}.



--
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-13366) AutoScalingConfig 'Invalid stage name' warnings after upgrade

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13366:


Commit e88a307eba4eaf94c482bedb19f8b0c304131a21 in lucene-solr's branch 
refs/heads/branch_7_7 from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e88a307 ]

SOLR-13366: Clarify 'Invalid stage name' warning logging in AutoScalingConfig

(Cherry picked from cae323629e437c47855c4c8578f76310fd2b7b84)


> AutoScalingConfig 'Invalid stage name' warnings after upgrade
> -
>
> Key: SOLR-13366
> URL: https://issues.apache.org/jira/browse/SOLR-13366
> Project: Solr
>  Issue Type: Bug
>  Components: AutoScaling
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13366.patch, SOLR-13366.patch
>
>
> I noticed WARNings like this in some of our logs:
> {code:java}
> ... OverseerAutoScalingTriggerThread ... o.a.s.c.s.c.a.AutoScalingConfig 
> Invalid stage name '.auto_add_replicas.system' in listener config, skipping: 
> {beforeAction=[], afterAction=[], trigger=.auto_add_replicas, stage=[WAITING, 
> STARTED, ABORTED, SUCCEEDED, FAILED, BEFORE_ACTION, AFTER_ACTION], 
> class=org.apache.solr.cloud.autoscaling.SystemLogListener}
> {code}
> After some detective work I think I've tracked this down to 7.1.0 
> [TriggerEventProcessorStage|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.1.0/solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/TriggerEventProcessorStage.java]
>  having a {{WAITING}} stage and that stage having been removed in 7.2.0 
> [TriggerEventProcessorStage|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.2.0/solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/TriggerEventProcessorStage.java]
>  via the SOLR-11320 changes. Haven't tried to reproduce it but my theory is 
> that the listener got auto-created (with the {{WAITING}} stage) when the 
> cloud was running pre-7.2.0 code and then after upgrading the warnings start 
> to appear.



--
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-13352) possible deadlock/threadleak from OverseerTriggerThread/AutoScalingWatcher during close()

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13352:


Commit 97bb70e73710a701abeed2997d535bc0fc98d7a5 in lucene-solr's branch 
refs/heads/branch_7_7 from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=97bb70e ]

SOLR-13352: Remove risk of deadlock/threadleak when shutting down an 
Overseer(TriggerThread)

(cherry picked from commit 1071d093360b2c5869a918de743c7089952094f4)


> possible deadlock/threadleak from OverseerTriggerThread/AutoScalingWatcher 
> during close()
> -
>
> Key: SOLR-13352
> URL: https://issues.apache.org/jira/browse/SOLR-13352
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13352.patch, 
> sarowe_Lucene-Solr-tests-master_20462.log.txt
>
>
> A recent jenkins failure in TestSimTriggerIntegration lead me to what appears 
> to be a "lock leak" situation in OverseerTriggerThread in how the 
> "updateLock" object is dealt with in the event that the OverseerTriggerThread 
> is closed.
> It's possible that this only affects tests using the SimCloudManager when 
> calling "simRestartOverseer" -- but 
> I _believe_ this can lead also lead to an actual deadlock / threadleak 
> situation in a thread running AutoScalingWatcher (that hold a refrefrences to 
> OverseerTriggerThread and every object reachable from it) when the 
> OverseerTriggerThread is closed as part of a real Solr shutdown ... which i 
> think would cause the JVM to stall untill externally killed.
> 
> If my analysis of the test failure (to follow in comment) is correct, then 
> even even if this bug isn't likely to affect real world solr instances (and 
> only surfaces because of how OverseerTriggerThread is used in 
> SimCloudManager) the fix to OverseerTriggerThread is a trivial change to 
> follow locking best practices (patch to follow)



--
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-13254) wrong log when reconnect to zk

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13254:


Commit 6c7278117c6712147580731a4d6ff6d4019e452d in lucene-solr's branch 
refs/heads/branch_7_7 from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6c72781 ]

SOLR-13254: Correct message that is logged in solrj's ConnectionManager when an 
exception occurred while reconnecting to ZooKeeper. (hu xiaodong via Christine 
Poerschke)

(cherry picked from commit 683aa3d3e9b7e8d66b5be737dade3ffc0690c7c5)


> wrong log when reconnect to zk
> --
>
> Key: SOLR-13254
> URL: https://issues.apache.org/jira/browse/SOLR-13254
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.7
>Reporter: hu xiaodong
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13254.patch
>
>
> When exception occurred while reconnecting to zk, it is clear that it waits 
> for 5 seconds and retry, but the log does recorded 1 second.



--
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] [Closed] (SOLR-13171) Make it possible to stream query result without creating java objects

[David Smiley (JIRA)]

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

David Smiley closed SOLR-13171.
---

> Make it possible to stream query result without creating java objects
> -
>
> Key: SOLR-13171
> URL: https://issues.apache.org/jira/browse/SOLR-13171
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-13171.patch
>
>
> When a query response is parsed , provide a way to consume it one field at a 
> time and without creating any  java objects



--
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-13171) Make it possible to stream query result without creating java objects

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-13171.
-
   Resolution: Fixed
Fix Version/s: 8.1

Please remember to "Resolve" your committed issues [~noble.paul].

> Make it possible to stream query result without creating java objects
> -
>
> Key: SOLR-13171
> URL: https://issues.apache.org/jira/browse/SOLR-13171
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-13171.patch
>
>
> When a query response is parsed , provide a way to consume it one field at a 
> time and without creating any  java objects



--
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: Lucene/Solr 7.7.2

[Jan Høydahl]

Here is the first draft of the release notes for Lucene and Solr 7.7.2

https://wiki.apache.org/lucene-java/ReleaseNote772
https://wiki.apache.org/solr/ReleaseNote772

I see no reason for choosing some of the 25 Solr bug fixes to highlight.
Some of them are high imact and some are security related, should we
perhaps list the security related ones only (no CVEs but still important ones)

Feel free to edit if you find copy/paste mistakes or if you have opinions on 
what bigfixes to highlight

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

> 16. mai 2019 kl. 17:38 skrev Jan Høydahl :
> 
> So now backCompat indices for 6.6.6 are pushed, smoketester should be happy.
> 
> I have also backported these JIRAs, ready to push to branch_7_7, currently 
> running tests:
> 
> SOLR-13229:  Cleanup replicasMetTragicEvent after all exceptions
> SOLR-13352:  Remove risk of deadlock/threadleak when shutting down an 
> Overseer(TriggerThread)
> SOLR-13366:  Clarify 'Invalid stage name' warning logging in AutoScalingConfig
> SOLR-13386:  OverseerTaskQueue#remove should not throw an exception when no 
> node exists after... 
> SOLR-13398:  Move log "Processing SSL Credential Provider chain" from INFO to 
> DEBUG to prevent...
> LUCENE-8720: fix int overflow in NameIntCacheLRU
> SOLR-13252:  Fix an NPE when setting a "policy" property for an existing 
> collection.
> SOLR-13254:  Correct message that is logged in solrj's ConnectionManager when 
> an exception…
> 
> I see no BLOCKERS, and the only JIRA I have on my list for potential backport 
> now is
> SOLR-12833:  Use timed-out lock in DistributedUpdateProcessor
> 
> Ishan, Hoss, Andrzej, Smiley, you recently worked with it, what is your 
> evaluation of whether it should go in 7.7.2?
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
>> 14. mai 2019 kl. 15:38 skrev Ishan Chattopadhyaya > >:
>> 
>>> I would like to backport SOLR-13410, as without this the ADDROLE of
>>> "overseer" is effectively broken. Please let me know if that is fine.
>> 
>> Just backported this. Hope there's still some time for a Jenkins run or two.
>> 
>> On Tue, May 14, 2019 at 2:48 PM Jan Høydahl > > wrote:
>>> 
>>> Jenkins jobs for 7_7 were enabled today. Will build the first RC once we 
>>> the results of the first few runs.
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com 
>>> 
>>> 10. mai 2019 kl. 21:16 skrev Kevin Risden >> >:
>>> 
>>> Finished backport of SOLR-13112 for Jackson 2.9.8
>>> 
>>> Kevin Risden
>>> 
>>> 
>>> On Thu, May 9, 2019 at 6:57 PM Jan Høydahl >> > wrote:
 
 Looks safe to backport, go ahead!
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com 
 
 9. mai 2019 kl. 23:07 skrev Cassandra Targett >>> >:
 
 Someone brought https://issues.apache.org/jira/browse/SOLR-13112 
  to my attention today, 
 which upgraded the Jackson dependencies to 2.9.8. Would it be possible for 
 those to be backported to branch_7_7 for inclusion in 7.7.2?
 
 Cassandra
 On May 8, 2019, 2:51 PM -0500, Jan Høydahl >>> >, wrote:
 
 Yes please do!
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com 
 
 8. mai 2019 kl. 18:25 skrev Ishan Chattopadhyaya 
 mailto:ichattopadhy...@gmail.com>>:
 
 I would like to backport SOLR-13410, as without this the ADDROLE of
 "overseer" is effectively broken. Please let me know if that is fine.
 
 On Sat, May 4, 2019 at 2:22 AM Jan Høydahl >>> > wrote:
 
 
 Sure, go ahead!
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com 
 
 3. mai 2019 kl. 17:53 skrev Andrzej Białecki 
 mailto:andrzej.biale...@lucidworks.com>>:
 
 Hi,
 
 I would like to back-port the recent changes in the re-opened SOLR-12833, 
 since the increased memory consumption adversely affects existing 7x users.
 
 On 3 May 2019, at 10:38, Jan Høydahl >>> > wrote:
 
 To not confuse two releases at the same time, I'll delay the first 7.7.2 
 RC until after a successful 8.1 vote.
 Uwe, can you re-enable the Jenkins 7.7 jobs to make sure we have a healthy 
 branch_7_7?
 Feel free to push important bug fixes to the branch in the meantime, 
 announcing them in this thread.
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com 
 

Re: Lucene/Solr 7.7.2

[Andrzej Białecki]

Bulk of SOLR-12833 (including recent changes) should already be there because 
it was committed to branch_7_7, with the exception of 
cde00b9a84f3d57252d34daaa77f2b56cf9802cb which still needs to be merged to 7_7 
and now to 7_7_2.

> On 16 May 2019, at 17:38, Jan Høydahl  wrote:
> 
> So now backCompat indices for 6.6.6 are pushed, smoketester should be happy.
> 
> I have also backported these JIRAs, ready to push to branch_7_7, currently 
> running tests:
> 
> SOLR-13229:  Cleanup replicasMetTragicEvent after all exceptions
> SOLR-13352:  Remove risk of deadlock/threadleak when shutting down an 
> Overseer(TriggerThread)
> SOLR-13366:  Clarify 'Invalid stage name' warning logging in AutoScalingConfig
> SOLR-13386:  OverseerTaskQueue#remove should not throw an exception when no 
> node exists after... 
> SOLR-13398:  Move log "Processing SSL Credential Provider chain" from INFO to 
> DEBUG to prevent...
> LUCENE-8720: fix int overflow in NameIntCacheLRU
> SOLR-13252:  Fix an NPE when setting a "policy" property for an existing 
> collection.
> SOLR-13254:  Correct message that is logged in solrj's ConnectionManager when 
> an exception…
> 
> I see no BLOCKERS, and the only JIRA I have on my list for potential backport 
> now is
> SOLR-12833:  Use timed-out lock in DistributedUpdateProcessor
> 
> Ishan, Hoss, Andrzej, Smiley, you recently worked with it, what is your 
> evaluation of whether it should go in 7.7.2?
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
>> 14. mai 2019 kl. 15:38 skrev Ishan Chattopadhyaya > >:
>> 
>>> I would like to backport SOLR-13410, as without this the ADDROLE of
>>> "overseer" is effectively broken. Please let me know if that is fine.
>> 
>> Just backported this. Hope there's still some time for a Jenkins run or two.
>> 
>> On Tue, May 14, 2019 at 2:48 PM Jan Høydahl > > wrote:
>>> 
>>> Jenkins jobs for 7_7 were enabled today. Will build the first RC once we 
>>> the results of the first few runs.
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com 
>>> 
>>> 10. mai 2019 kl. 21:16 skrev Kevin Risden >> >:
>>> 
>>> Finished backport of SOLR-13112 for Jackson 2.9.8
>>> 
>>> Kevin Risden
>>> 
>>> 
>>> On Thu, May 9, 2019 at 6:57 PM Jan Høydahl >> > wrote:
 
 Looks safe to backport, go ahead!
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com 
 
 9. mai 2019 kl. 23:07 skrev Cassandra Targett >>> >:
 
 Someone brought https://issues.apache.org/jira/browse/SOLR-13112 
  to my attention today, 
 which upgraded the Jackson dependencies to 2.9.8. Would it be possible for 
 those to be backported to branch_7_7 for inclusion in 7.7.2?
 
 Cassandra
 On May 8, 2019, 2:51 PM -0500, Jan Høydahl >>> >, wrote:
 
 Yes please do!
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com 
 
 8. mai 2019 kl. 18:25 skrev Ishan Chattopadhyaya 
 mailto:ichattopadhy...@gmail.com>>:
 
 I would like to backport SOLR-13410, as without this the ADDROLE of
 "overseer" is effectively broken. Please let me know if that is fine.
 
 On Sat, May 4, 2019 at 2:22 AM Jan Høydahl >>> > wrote:
 
 
 Sure, go ahead!
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com 
 
 3. mai 2019 kl. 17:53 skrev Andrzej Białecki 
 mailto:andrzej.biale...@lucidworks.com>>:
 
 Hi,
 
 I would like to back-port the recent changes in the re-opened SOLR-12833, 
 since the increased memory consumption adversely affects existing 7x users.
 
 On 3 May 2019, at 10:38, Jan Høydahl >>> > wrote:
 
 To not confuse two releases at the same time, I'll delay the first 7.7.2 
 RC until after a successful 8.1 vote.
 Uwe, can you re-enable the Jenkins 7.7 jobs to make sure we have a healthy 
 branch_7_7?
 Feel free to push important bug fixes to the branch in the meantime, 
 announcing them in this thread.
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com 
 
 30. apr. 2019 kl. 18:19 skrev Ishan Chattopadhyaya 
 mailto:ichattopadhy...@gmail.com>>:
 
 +1 Jan for May 7th.
 Hopefully, 8.1 would be already out by then (or close to being there).
 
 On Tue, Apr 30, 2019 at 1:33 PM Bram Van Dam >>> > wrote:
 
 
 On 29/04/2019 

Re: Lucene/Solr 7.7.2

[Uwe Schindler]

Did you include the one that disables Jetty directory listings?

Am May 16, 2019 3:38:32 PM UTC schrieb "Jan Høydahl" :
>So now backCompat indices for 6.6.6 are pushed, smoketester should be
>happy.
>
>I have also backported these JIRAs, ready to push to branch_7_7,
>currently running tests:
>
>SOLR-13229:  Cleanup replicasMetTragicEvent after all exceptions
>SOLR-13352:  Remove risk of deadlock/threadleak when shutting down an
>Overseer(TriggerThread)
>SOLR-13366:  Clarify 'Invalid stage name' warning logging in
>AutoScalingConfig
>SOLR-13386:  OverseerTaskQueue#remove should not throw an exception
>when no node exists after... 
>SOLR-13398:  Move log "Processing SSL Credential Provider chain" from
>INFO to DEBUG to prevent...
>LUCENE-8720: fix int overflow in NameIntCacheLRU
>SOLR-13252:  Fix an NPE when setting a "policy" property for an
>existing collection.
>SOLR-13254:  Correct message that is logged in solrj's
>ConnectionManager when an exception…
>
>I see no BLOCKERS, and the only JIRA I have on my list for potential
>backport now is
>SOLR-12833:  Use timed-out lock in DistributedUpdateProcessor
>
>Ishan, Hoss, Andrzej, Smiley, you recently worked with it, what is your
>evaluation of whether it should go in 7.7.2?
>
>--
>Jan Høydahl, search solution architect
>Cominvent AS - www.cominvent.com
>
>> 14. mai 2019 kl. 15:38 skrev Ishan Chattopadhyaya
>:
>> 
>>> I would like to backport SOLR-13410, as without this the ADDROLE of
>>> "overseer" is effectively broken. Please let me know if that is
>fine.
>> 
>> Just backported this. Hope there's still some time for a Jenkins run
>or two.
>> 
>> On Tue, May 14, 2019 at 2:48 PM Jan Høydahl 
>wrote:
>>> 
>>> Jenkins jobs for 7_7 were enabled today. Will build the first RC
>once we the results of the first few runs.
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
>>> 10. mai 2019 kl. 21:16 skrev Kevin Risden :
>>> 
>>> Finished backport of SOLR-13112 for Jackson 2.9.8
>>> 
>>> Kevin Risden
>>> 
>>> 
>>> On Thu, May 9, 2019 at 6:57 PM Jan Høydahl 
>wrote:
 
 Looks safe to backport, go ahead!
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com
 
 9. mai 2019 kl. 23:07 skrev Cassandra Targett
>:
 
 Someone brought https://issues.apache.org/jira/browse/SOLR-13112 to
>my attention today, which upgraded the Jackson dependencies to 2.9.8.
>Would it be possible for those to be backported to branch_7_7 for
>inclusion in 7.7.2?
 
 Cassandra
 On May 8, 2019, 2:51 PM -0500, Jan Høydahl ,
>wrote:
 
 Yes please do!
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com
 
 8. mai 2019 kl. 18:25 skrev Ishan Chattopadhyaya
>:
 
 I would like to backport SOLR-13410, as without this the ADDROLE of
 "overseer" is effectively broken. Please let me know if that is
>fine.
 
 On Sat, May 4, 2019 at 2:22 AM Jan Høydahl 
>wrote:
 
 
 Sure, go ahead!
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com
 
 3. mai 2019 kl. 17:53 skrev Andrzej Białecki
>:
 
 Hi,
 
 I would like to back-port the recent changes in the re-opened
>SOLR-12833, since the increased memory consumption adversely affects
>existing 7x users.
 
 On 3 May 2019, at 10:38, Jan Høydahl  wrote:
 
 To not confuse two releases at the same time, I'll delay the first
>7.7.2 RC until after a successful 8.1 vote.
 Uwe, can you re-enable the Jenkins 7.7 jobs to make sure we have a
>healthy branch_7_7?
 Feel free to push important bug fixes to the branch in the
>meantime, announcing them in this thread.
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com
 
 30. apr. 2019 kl. 18:19 skrev Ishan Chattopadhyaya
>:
 
 +1 Jan for May 7th.
 Hopefully, 8.1 would be already out by then (or close to being
>there).
 
 On Tue, Apr 30, 2019 at 1:33 PM Bram Van Dam 
>wrote:
 
 
 On 29/04/2019 23:33, Jan Høydahl wrote:
 
 I'll vounteer as RM for 7.7.2 and aim at first RC on Tuesday May
>7th
 
 
 Thank you!
 
 
 
 
 

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

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

[jira] [Commented] (SOLR-13473) Ensure that the tests use JSON,javabin to update docs

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-13473:
---

Could we randomize it instead? And doing anything similar for queries where we 
pass in XPath strings I'll leave for later ;)

> Ensure that the tests use JSON,javabin to update docs
> -
>
> Key: SOLR-13473
> URL: https://issues.apache.org/jira/browse/SOLR-13473
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> {{SolrTestCaseJ4#assertU}} sends documents as XML. XML is a very uncommon 
> update format .
> We should change it to use JSON/javabin 



--
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-13268) Clean up any test failures resulting from defaulting to async logging

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-13268:
--
Priority: Major  (was: Blocker)

Changing from blocker. That was to make sure that at least some attention got 
paid to this issue and it didn't get lost in the process.

Given that I'm pretty sure it's a function of the test framework and it's 
become quite rare even in the test situations, I don't think it needs to be a 
blocker.

> Clean up any test failures resulting from defaulting to async logging
> -
>
> Key: SOLR-13268
> URL: https://issues.apache.org/jira/browse/SOLR-13268
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13268-flushing.patch, SOLR-13268.patch, 
> SOLR-13268.patch, SOLR-13268.patch
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This is a catch-all for test failures due to the async logging changes. So 
> far, the I see a couple failures on JDK13 only. I'll collect a "starter set" 
> here, these are likely systemic, once the root cause is found/fixed, then 
> others are likely fixed as well.
> JDK13:
> ant test  -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV 
> -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ant test  -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk 
> -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8



--
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-13474) Fix "Search is temporarily disabled" logic to be consistent for entire request

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-13474:
-

+1  -- but hopefully [~noble.paul] can review too.
Thanks so much for both investigating and fixing all these bugs introduced by 
SOLR-12999.  I wish it had a code review.

> Fix "Search is temporarily disabled" logic to be consistent for entire request
> --
>
> Key: SOLR-13474
> URL: https://issues.apache.org/jira/browse/SOLR-13474
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13474.patch
>
>
> Where/How the "Search is temporarily disabled" logic was added in SOLR-12999 
> can result in some weird failure cases (examples: SOLR-13470 & SOLR-13471) 
> due to the fact that  (as currently implemented) some portions of processing 
> a SolrQueryRequest may see a valid searcher, but later other code paths will 
> get an error when trying to use the same searcher.
> I think it would make more sense to move the "searchEnabled" logic out of 
> {{SolrQueryRequestbase.getSearcher()}} and into {{SolrCore.getSearcher()}} 
> (removing the need for {{SolrCore.isSearchEnabled()}} ).
> This will:
>  * restore the long standing (and widly assumed by code) behavior of 
> {{SolrQueryRequestbase.getSearcher()}} that it will always return a 
> consistent result
>  * ensure that any custom plugins trying to call {{SolrCore.getSearcher()}} 
> directly will also get the benefits of the safety checks introduced in 
> SOLR-12999



--
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] [Comment Edited] (SOLR-12833) Use timed-out lock in DistributedUpdateProcessor

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  edited comment on SOLR-12833 at 5/16/19 3:47 PM:
---

Looks like this hasn't been merged to 7x or 7_7 :
* cde00b9a84f3d57252d34daaa77f2b56cf9802cb prevent NPE in 
DistributedUpdateProcessorTest AfterClass when mockito assumption fails in 
BeforeClass

I checked that the content from other commits seems to be already included in 
commits for this issue on these branches. 


was (Author: ab):
Looks like this hasn't been merged to 7x or 7_7 :
* cde00b9a84f3d57252d34daaa77f2b56cf9802cb prevent NPE in 
DistributedUpdateProcessorTest AfterClass when mockito assumption fails in 
BeforeClass

I checked that the content from other commits seems to be already included in 
other commits for this issue on these branches. 

> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 7.7, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch, threadDump.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
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-12833) Use timed-out lock in DistributedUpdateProcessor

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12833:
--

Looks like this hasn't been merged to 7x or 7_7 :
* cde00b9a84f3d57252d34daaa77f2b56cf9802cb prevent NPE in 
DistributedUpdateProcessorTest AfterClass when mockito assumption fails in 
BeforeClass

I checked that the content from other commits seems to be already included in 
other commits for this issue on these branches. 

> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 7.7, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch, threadDump.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
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-12) - Build # 24090 - Still Failing!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 58603 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:634: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:507: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:494: Source checkout 
is dirty (unversioned/missing files) after running tests!!! Offending files:
* solr/licenses/noggit-0.8.jar.sha1

Total time: 70 minutes 58 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

Re: Lucene/Solr 7.7.2

[Jan Høydahl]

So now backCompat indices for 6.6.6 are pushed, smoketester should be happy.

I have also backported these JIRAs, ready to push to branch_7_7, currently 
running tests:

SOLR-13229:  Cleanup replicasMetTragicEvent after all exceptions
SOLR-13352:  Remove risk of deadlock/threadleak when shutting down an 
Overseer(TriggerThread)
SOLR-13366:  Clarify 'Invalid stage name' warning logging in AutoScalingConfig
SOLR-13386:  OverseerTaskQueue#remove should not throw an exception when no 
node exists after... 
SOLR-13398:  Move log "Processing SSL Credential Provider chain" from INFO to 
DEBUG to prevent...
LUCENE-8720: fix int overflow in NameIntCacheLRU
SOLR-13252:  Fix an NPE when setting a "policy" property for an existing 
collection.
SOLR-13254:  Correct message that is logged in solrj's ConnectionManager when 
an exception…

I see no BLOCKERS, and the only JIRA I have on my list for potential backport 
now is
SOLR-12833:  Use timed-out lock in DistributedUpdateProcessor

Ishan, Hoss, Andrzej, Smiley, you recently worked with it, what is your 
evaluation of whether it should go in 7.7.2?

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

> 14. mai 2019 kl. 15:38 skrev Ishan Chattopadhyaya :
> 
>> I would like to backport SOLR-13410, as without this the ADDROLE of
>> "overseer" is effectively broken. Please let me know if that is fine.
> 
> Just backported this. Hope there's still some time for a Jenkins run or two.
> 
> On Tue, May 14, 2019 at 2:48 PM Jan Høydahl  wrote:
>> 
>> Jenkins jobs for 7_7 were enabled today. Will build the first RC once we the 
>> results of the first few runs.
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>> 10. mai 2019 kl. 21:16 skrev Kevin Risden :
>> 
>> Finished backport of SOLR-13112 for Jackson 2.9.8
>> 
>> Kevin Risden
>> 
>> 
>> On Thu, May 9, 2019 at 6:57 PM Jan Høydahl  wrote:
>>> 
>>> Looks safe to backport, go ahead!
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
>>> 9. mai 2019 kl. 23:07 skrev Cassandra Targett :
>>> 
>>> Someone brought https://issues.apache.org/jira/browse/SOLR-13112 to my 
>>> attention today, which upgraded the Jackson dependencies to 2.9.8. Would it 
>>> be possible for those to be backported to branch_7_7 for inclusion in 7.7.2?
>>> 
>>> Cassandra
>>> On May 8, 2019, 2:51 PM -0500, Jan Høydahl , wrote:
>>> 
>>> Yes please do!
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
>>> 8. mai 2019 kl. 18:25 skrev Ishan Chattopadhyaya 
>>> :
>>> 
>>> I would like to backport SOLR-13410, as without this the ADDROLE of
>>> "overseer" is effectively broken. Please let me know if that is fine.
>>> 
>>> On Sat, May 4, 2019 at 2:22 AM Jan Høydahl  wrote:
>>> 
>>> 
>>> Sure, go ahead!
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
>>> 3. mai 2019 kl. 17:53 skrev Andrzej Białecki 
>>> :
>>> 
>>> Hi,
>>> 
>>> I would like to back-port the recent changes in the re-opened SOLR-12833, 
>>> since the increased memory consumption adversely affects existing 7x users.
>>> 
>>> On 3 May 2019, at 10:38, Jan Høydahl  wrote:
>>> 
>>> To not confuse two releases at the same time, I'll delay the first 7.7.2 RC 
>>> until after a successful 8.1 vote.
>>> Uwe, can you re-enable the Jenkins 7.7 jobs to make sure we have a healthy 
>>> branch_7_7?
>>> Feel free to push important bug fixes to the branch in the meantime, 
>>> announcing them in this thread.
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
>>> 30. apr. 2019 kl. 18:19 skrev Ishan Chattopadhyaya 
>>> :
>>> 
>>> +1 Jan for May 7th.
>>> Hopefully, 8.1 would be already out by then (or close to being there).
>>> 
>>> On Tue, Apr 30, 2019 at 1:33 PM Bram Van Dam  wrote:
>>> 
>>> 
>>> On 29/04/2019 23:33, Jan Høydahl wrote:
>>> 
>>> I'll vounteer as RM for 7.7.2 and aim at first RC on Tuesday May 7th
>>> 
>>> 
>>> Thank you!
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -
>>> 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
> 

Re: Solr 8.1 issue with collection aliases

[Andrzej Białecki]

Yes, I can work on 8.1.1 release - I’ll announce this shortly.

> On 16 May 2019, at 13:51, Ishan Chattopadhyaya  
> wrote:
> 
> Absolutely. This is a critical feature.
> Andrzej, would you have time to do a 8.1.1 release? We also need to
> coordinate with Jan, since he's doing a 7.7.2 release right now.
> 
> On Thu, May 16, 2019 at 5:18 PM Jörn Franke  wrote:
>> 
>> For the specific client the Solr 8.1 is not usable with this bug.
>> 
>> Collection aliases are also a crucial feature for doing “zero-downtime” 
>> reindexing or changing the Schema of a collection or for switching back to 
>> an old Index if the new Index structure has bugs etc.
>> 
>> However  I also understand that there are other considerations by other 
>> people.
>> 
>>> Am 16.05.2019 um 11:55 schrieb Ishan Chattopadhyaya 
>>> :
>>> 
>>> Does this warrant a 8.1.1 release? I think this is serious enough.
>>> 
 On Thu, May 16, 2019 at 12:03 PM Jörn Franke  wrote:
 
 SOLR-13475
 
> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya 
> :
> 
> Please open a JIRA.
> 
>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke,  wrote:
>> Sorry autocorrection. It is not only a admin UI issue. I described in my 
>> previous email that access through the collection alias does not work. I 
>> cannot even do execute the select query handler if I use the collection 
>> alias instead of the collection name.
>> So it is maybe more problematic.
>> 
>>> Am 16.05.2019 um 04:36 schrieb Jörn Franke :
>>> 
>>> Note only an admin UI issue. Access collections via their alias does 
>>> not work.
>>> 
 Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
 
 It seems creating alias in Solr Admin UI is broken. It's a minor issue 
 for 8.1.0
 I've alias via REST call 
 http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
   successfully.
 Jörn, thanks for reporting.
 
> On Tue, May 14, 2019 at 11:03 PM Jörn Franke  
> wrote:
> Hi,
> 
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue 
> with
> collection aliases, but I am not 100% sure it is due to the upgrade.
> 
> Situation:
> I have a collection called c_testcollection.
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue
> 
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> http://localhost:8983/solr/c_testcollection/select?q=test
> When I do a query on testcollection then I receive the stacktrace 
> below
> http://localhost:8983/solr/testcollection/select?q=test
> 
> Additionally I observe a strange behavior in the admin ui. When I try 
> to
> create an alias (e.g. new) for a new collection (e.g. c_new) then it
> creates two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I 
> remove
> the alias from c_new to c_new then I get the same error. Is this 
> desired
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to 
> filter
> them out in my application when retrieving all aliases.
> Is there a related issue.
> 
> Here the stacktrace:
> {
> "error":{
>   "trace":"java.lang.NullPointerException\n\tat
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
> 

[jira] [Commented] (SOLR-12833) Use timed-out lock in DistributedUpdateProcessor

[JIRA]

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

Jan Høydahl commented on SOLR-12833:


This was reopened in April, more commits made in May, but is also has 
FixVersion 7.7. Should there not have been a new Jira instead of re-open since 
7.7 was already released?

Trying to understand whether I need to backport this to 7.7.2. 
[~markrmil...@gmail.com]?

> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 7.7, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch, threadDump.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
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-13268) Clean up any test failures resulting from defaulting to async logging

[JIRA]

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

Jan Høydahl commented on SOLR-13268:


his Jira has several commits, is a Blocker but has no Fix Version.??

> Clean up any test failures resulting from defaulting to async logging
> -
>
> Key: SOLR-13268
> URL: https://issues.apache.org/jira/browse/SOLR-13268
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Blocker
> Attachments: SOLR-13268-flushing.patch, SOLR-13268.patch, 
> SOLR-13268.patch, SOLR-13268.patch
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This is a catch-all for test failures due to the async logging changes. So 
> far, the I see a couple failures on JDK13 only. I'll collect a "starter set" 
> here, these are likely systemic, once the root cause is found/fixed, then 
> others are likely fixed as well.
> JDK13:
> ant test  -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV 
> -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ant test  -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk 
> -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8



--
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-repro - Build # 3265 - Unstable

[Apache Jenkins Server]

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

[...truncated 29 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.7/12/consoleText

[repro] Revision: b520318ae6380a67f7b7d20c6bad594c3f1e6fdc

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.7/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=TestStressCloudBlindAtomicUpdates 
-Dtests.method=test_dv_idx -Dtests.seed=830E38476CC7F41 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.7/test-data/enwiki.random.lines.txt
 -Dtests.locale=uk-UA -Dtests.timezone=Europe/Kirov -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[...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]   TestStressCloudBlindAtomicUpdates
[repro] ant compile-test

[...truncated 3585 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestStressCloudBlindAtomicUpdates" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.7/test-data/enwiki.random.lines.txt
 -Dtests.seed=830E38476CC7F41 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.7/test-data/enwiki.random.lines.txt
 -Dtests.locale=uk-UA -Dtests.timezone=Europe/Kirov -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   2/5 failed: org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates
[repro] git checkout c726ada1d99fcc4b15cb9f4877aad34d30a2d56e

[...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] [Updated] (SOLR-13229) ZkController.giveupLeadership should cleanup the replicasMetTragicEvent map after all exceptions

[JIRA]

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

Jan Høydahl updated SOLR-13229:
---
Fix Version/s: 7.7.2

> ZkController.giveupLeadership should cleanup the replicasMetTragicEvent map 
> after all exceptions
> 
>
> Key: SOLR-13229
> URL: https://issues.apache.org/jira/browse/SOLR-13229
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Fix For: 7.7.2, 8.1, master (9.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently {{ZkController.giveupLeadership}} cleans up the 
> {{replicasMetTragicEvent}} after {{Keeper|Interrupted Exceptions}}, all other 
> exceptions should also cleanup



--
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-13386) Remove race in OverseerTaskQueue#remove that can result in the Overseer causing a Zookeeper call spin spike.

[JIRA]

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

Jan Høydahl updated SOLR-13386:
---
Fix Version/s: 7.7.2

> Remove race in OverseerTaskQueue#remove that can result in the Overseer 
> causing a Zookeeper call spin spike.
> 
>
> Key: SOLR-13386
> URL: https://issues.apache.org/jira/browse/SOLR-13386
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13386.patch
>
>
> If the data call hits NoNodeException, it will throw and the Overseer work 
> queue processor will catch it and loop and repeat, which causes major zk 
> getData / NoNode call traffic or other such things.



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

[GitHub] [lucene-solr] thomaswoeckinger commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347

[GitBox]

thomaswoeckinger commented on issue #665: Fixes SOLR-11841, SOLR-13331, 
SOLR-13347
URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-493093718
 
 
   Is it better for you if put the formatting in an seperate commit, i think
   if i create a new pr this will never get merged, otherwise the format would
   not be in the current state.
   
   Jan Høydahl  schrieb am Do., 16. Mai 2019, 15:19:
   
   > There is stil a TON of unrelated whitespace changes in the patch. If you
   > want to reformat code, best practice is to open another PR for that
   > separately.
   >
   > What I normally do to clean up is first disable the aggressive
   > reformatting feature in the IDE, then open "Compare with branch ..." in my
   > IDE (IntelliJ) and in the diff view, click restore on every single diff
   > change that is messed up by the IDE, then commit and push those changes.
   > You'll then see that your diff becomes MUCH smaller and easier to read!
   >
   > —
   > You are receiving this because you authored the thread.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or mute the thread
   > 

   > .
   >
   


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


With regards,
Apache Git Services

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

[jira] [Updated] (SOLR-13352) possible deadlock/threadleak from OverseerTriggerThread/AutoScalingWatcher during close()

[JIRA]

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

Jan Høydahl updated SOLR-13352:
---
Fix Version/s: 7.7.2

> possible deadlock/threadleak from OverseerTriggerThread/AutoScalingWatcher 
> during close()
> -
>
> Key: SOLR-13352
> URL: https://issues.apache.org/jira/browse/SOLR-13352
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13352.patch, 
> sarowe_Lucene-Solr-tests-master_20462.log.txt
>
>
> A recent jenkins failure in TestSimTriggerIntegration lead me to what appears 
> to be a "lock leak" situation in OverseerTriggerThread in how the 
> "updateLock" object is dealt with in the event that the OverseerTriggerThread 
> is closed.
> It's possible that this only affects tests using the SimCloudManager when 
> calling "simRestartOverseer" -- but 
> I _believe_ this can lead also lead to an actual deadlock / threadleak 
> situation in a thread running AutoScalingWatcher (that hold a refrefrences to 
> OverseerTriggerThread and every object reachable from it) when the 
> OverseerTriggerThread is closed as part of a real Solr shutdown ... which i 
> think would cause the JVM to stall untill externally killed.
> 
> If my analysis of the test failure (to follow in comment) is correct, then 
> even even if this bug isn't likely to affect real world solr instances (and 
> only surfaces because of how OverseerTriggerThread is used in 
> SimCloudManager) the fix to OverseerTriggerThread is a trivial change to 
> follow locking best practices (patch to follow)



--
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-13366) AutoScalingConfig 'Invalid stage name' warnings after upgrade

[JIRA]

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

Jan Høydahl updated SOLR-13366:
---
Fix Version/s: 7.7.2

> AutoScalingConfig 'Invalid stage name' warnings after upgrade
> -
>
> Key: SOLR-13366
> URL: https://issues.apache.org/jira/browse/SOLR-13366
> Project: Solr
>  Issue Type: Bug
>  Components: AutoScaling
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13366.patch, SOLR-13366.patch
>
>
> I noticed WARNings like this in some of our logs:
> {code:java}
> ... OverseerAutoScalingTriggerThread ... o.a.s.c.s.c.a.AutoScalingConfig 
> Invalid stage name '.auto_add_replicas.system' in listener config, skipping: 
> {beforeAction=[], afterAction=[], trigger=.auto_add_replicas, stage=[WAITING, 
> STARTED, ABORTED, SUCCEEDED, FAILED, BEFORE_ACTION, AFTER_ACTION], 
> class=org.apache.solr.cloud.autoscaling.SystemLogListener}
> {code}
> After some detective work I think I've tracked this down to 7.1.0 
> [TriggerEventProcessorStage|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.1.0/solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/TriggerEventProcessorStage.java]
>  having a {{WAITING}} stage and that stage having been removed in 7.2.0 
> [TriggerEventProcessorStage|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.2.0/solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/TriggerEventProcessorStage.java]
>  via the SOLR-11320 changes. Haven't tried to reproduce it but my theory is 
> that the listener got auto-created (with the {{WAITING}} stage) when the 
> cloud was running pre-7.2.0 code and then after upgrading the warnings start 
> to appear.



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

[GitHub] [lucene-solr] martin-g commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347

[GitBox]

martin-g commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347
URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-493091734
 
 
   One can easily hide the white space changes in Github UI by pressing the `No 
whitespace` button (or add manually `?w=1` to the url).


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


With regards,
Apache Git Services

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

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 362 - Failure

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI

Error Message:
{} expected:<2> but was:<0>

Stack Trace:
java.lang.AssertionError: {} expected:<2> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([F51810F748FFD28C:EACF8CDB3BF42BC7]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:293)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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:834)




Build Log:
[...truncated 13563 lines...]
   [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest
   [junit4]   2> 2388337 INFO  
(SUITE-AliasIntegrationTest-seed#[F51810F748FFD28C]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & 

[jira] [Updated] (SOLR-13398) Move log "Processing SSL Credential Provider chain" from INFO to DEBUG

[JIRA]

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

Jan Høydahl updated SOLR-13398:
---
Fix Version/s: 7.7.2

> Move log "Processing SSL Credential Provider chain" from INFO to DEBUG
> --
>
> Key: SOLR-13398
> URL: https://issues.apache.org/jira/browse/SOLR-13398
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Affects Versions: 8.0
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.7.2, 8.1
>
>
> Move log "Processing SSL Credential Provider chain" from INFO to DEBUG to 
> prevent this log line leaking into Terminal prompt when using {{bin/solr}}.



--
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-8720) Integer overflow bug in NameIntCacheLRU.makeRoomLRU()

[JIRA]

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

Jan Høydahl updated LUCENE-8720:

Fix Version/s: 7.7.2

> Integer overflow bug in NameIntCacheLRU.makeRoomLRU()
> -
>
> Key: LUCENE-8720
> URL: https://issues.apache.org/jira/browse/LUCENE-8720
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.7.1
> Environment: Mac OS X 10.11.6 but this bug is not affected by the 
> environment because it is a straightforward integer overflow bug.
>Reporter: Russell A Brown
>Priority: Major
>  Labels: easyfix, patch
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: LUCENE-.patch
>
>
> The NameIntCacheLRU.makeRoomLRU() method has an integer overflow bug because 
> if maxCacheSize >= Integer.MAX_VALUE/2, 2*maxCacheSize will overflow to 
> -(2^30) and the value of n will overflow to a negative integer as well, which 
> will prevent any clearing of the cache whatsoever. Hence, performance will 
> degrade once the cache becomes full because it will be impossible to remove 
> any entries in order to add new entries to the cache.
> Moreover, comments in NameIntCacheLRU.java and LruTaxonomyWriterCache.java 
> indicate that 2/3 of the cache will be cleared, whereas in fact only 1/3 of 
> the cache is cleared. So as not to change the behavior of the 
> NameIntCacheLRU.makeRoomLRU() method, I have not changed the code to clear 
> 2/3 of the cache but instead I have changed the comments to indicate that 1/3 
> of the cache is cleared.



--
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-master - Build # 1336 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1336/

No tests ran.

Build Log:
[...truncated 23471 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 2531 links (2070 relative) to 3360 anchors in 253 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/

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

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz
 into 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/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-master/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-master/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-master/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-master/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-master/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-master/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-master/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-master/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-master/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-master/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-master/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:

[jira] [Updated] (SOLR-13252) NPE trying to set autoscaling policy for existing collection

[JIRA]

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

Jan Høydahl updated SOLR-13252:
---
Fix Version/s: 7.7.2

> NPE trying to set autoscaling policy for existing collection
> 
>
> Key: SOLR-13252
> URL: https://issues.apache.org/jira/browse/SOLR-13252
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.7.2, 8.0, master (9.0)
>
> Attachments: SOLR-13252.patch
>
>
> Steps to reproduce:
> * create a collection without collection-specific policy, eg. {{test}}
> * define a collection-specific policy {{policy1}}:
> {code}
> POST http://localhost:8983/solr/admin/autoscaling
> {
> "set-policy": 
>   {
>   "policy1" :[
>   {"replica": "<2", "shard": "#EACH", "node": "#ANY"}
>   ]
>   }
> }
> {code}
> * try to modify the collection to use this policy
> {code}
> http://localhost:8983/solr/admin/collections?action=MODIFYCOLLECTION=test=policy1
> {code}
> A NullPointerException is thrown due to the previous value of the "policy" 
> property being absent:
> {code}
> 2019-02-14 18:48:17.007 ERROR 
> (OverseerThreadFactory-9-thread-5-processing-n:192.168.0.69:8983_solr) 
> [c:test   ] o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test 
> operation: modifycollection failed:java.lang.NullPointerException
> at 
> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.modifyCollection(OverseerCollectionMessageHandler.java:687)
> at 
> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:292)
> at 
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:496)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}



--
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-13254) wrong log when reconnect to zk

[JIRA]

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

Jan Høydahl updated SOLR-13254:
---
Fix Version/s: 7.7.2

> wrong log when reconnect to zk
> --
>
> Key: SOLR-13254
> URL: https://issues.apache.org/jira/browse/SOLR-13254
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.7
>Reporter: hu xiaodong
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13254.patch
>
>
> When exception occurred while reconnecting to zk, it is clear that it waits 
> for 5 seconds and retry, but the log does recorded 1 second.



--
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-8.x-Linux (64bit/jdk-12) - Build # 568 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/568/
Java: 64bit/jdk-12 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 2080 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/test/temp/junit4-J1-20190516_124717_1628211787346486874994.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/test/temp/junit4-J2-20190516_124717_1622997156370131611097.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 5 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/test/temp/junit4-J0-20190516_124717_1638967868325954898332.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 307 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/test-framework/test/temp/junit4-J2-20190516_125723_06115346019382449734744.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/test-framework/test/temp/junit4-J1-20190516_125723_0611416992628789900133.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/test-framework/test/temp/junit4-J0-20190516_125723_0615709036854349077943.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 1083 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/analysis/common/test/temp/junit4-J0-20190516_125854_35717275597218024219639.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/analysis/common/test/temp/junit4-J1-20190516_125854_3577620587361060620997.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/analysis/common/test/temp/junit4-J2-20190516_125854_35712319633881644433368.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 255 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J0-20190516_130040_24116384421943128194379.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J2-20190516_130040_24115915204980122444156.syserr
   [junit4] >>> JVM J2 emitted unexpected output 

[jira] [Commented] (SOLR-13475) Nullpointer-Exception when querying collection through collection alias

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13475:
--

[~jornfranke], [~ichattopadhyaya] - here's a patch (relative to branch_8x) that 
fixes the NPE. Please review & test it, if there are no objections I'll commit 
it to master / 8x. Fixing 8.1 is an open question at this point.

> Nullpointer-Exception when querying collection through collection alias
> ---
>
> Key: SOLR-13475
> URL: https://issues.apache.org/jira/browse/SOLR-13475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 8.1
>Reporter: Jörn Franke
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13475.patch
>
>
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
> collection aliases, but I am not 100% sure it is due to the upgrade.
>  
> Situation:
> I have a collection called c_testcollection. 
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue to query the collection through its alias 
> "testcollection", e.g 
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> [http://localhost:8983/solr/c_testcollection/select?q=test]
> When I do a query on testcollection then I receive the stacktrace below
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> Additionally I observe a strange behavior in the admin ui. When I try to 
> create an alias (e.g. new) for a new collection (e.g. c_new) then it creates 
> two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove 
> the alias from c_new to c_new then I get the same error. Is this desired 
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to filter 
> them out in my application when retrieving all aliases.
> Is there a related issue.
>  
> Here the stacktrace:
> {
>   "error":{
>     "trace":"java.lang.NullPointerException\n\tat 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>  
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>  org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>  
> 

[jira] [Updated] (SOLR-13475) Nullpointer-Exception when querying collection through collection alias

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13475:
-
Attachment: SOLR-13475.patch

> Nullpointer-Exception when querying collection through collection alias
> ---
>
> Key: SOLR-13475
> URL: https://issues.apache.org/jira/browse/SOLR-13475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 8.1
>Reporter: Jörn Franke
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13475.patch
>
>
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
> collection aliases, but I am not 100% sure it is due to the upgrade.
>  
> Situation:
> I have a collection called c_testcollection. 
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue to query the collection through its alias 
> "testcollection", e.g 
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> [http://localhost:8983/solr/c_testcollection/select?q=test]
> When I do a query on testcollection then I receive the stacktrace below
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> Additionally I observe a strange behavior in the admin ui. When I try to 
> create an alias (e.g. new) for a new collection (e.g. c_new) then it creates 
> two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove 
> the alias from c_new to c_new then I get the same error. Is this desired 
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to filter 
> them out in my application when retrieving all aliases.
> Is there a related issue.
>  
> Here the stacktrace:
> {
>   "error":{
>     "trace":"java.lang.NullPointerException\n\tat 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>  
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>  org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat 
> 

[jira] [Closed] (LUCENE-8801) IndexSearcher.search(Query, Collector) sends duplicate documents to collector when index is large enough

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev closed LUCENE-8801.


> IndexSearcher.search(Query, Collector) sends duplicate documents to collector 
> when index is large enough
> 
>
> Key: LUCENE-8801
> URL: https://issues.apache.org/jira/browse/LUCENE-8801
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.4, 8.0
>Reporter: Mikhail
>Priority: Major
> Attachments: DupesTest.java
>
>
> IndexSearcher.search(Query, Collector) repeatedly sends duplicate documents 
> to collector when index is large enough. Test attached.



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

[GitHub] [lucene-solr] janhoy commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347

[GitBox]

janhoy commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347
URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-493064161
 
 
   There is stil a TON of unrelated whitespace changes in the patch. If you 
want to reformat code, best practice is to open another PR for that separately.
   
   What I normally do to clean up is first disable the aggressive reformatting 
feature in the IDE, then open "Compare with branch ..." in my IDE (IntelliJ) 
and in the diff view, click restore on every single diff change that is messed 
up by the IDE, then commit and push those changes. You'll then see that your 
diff becomes MUCH smaller and easier to read!


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


With regards,
Apache Git Services

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+18) - Build # 24089 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24089/
Java: 64bit/jdk-13-ea+18 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 58609 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:634: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:507: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:494: Source checkout 
is dirty (unversioned/missing files) after running tests!!! Offending files:
* solr/licenses/noggit-0.8.jar.sha1

Total time: 72 minutes 23 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Resolved] (LUCENE-8801) IndexSearcher.search(Query, Collector) sends duplicate documents to collector when index is large enough

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev resolved LUCENE-8801.
--
Resolution: Not A Bug

Pls check core lucene concept at first 
https://lucene.apache.org/core/5_2_0/core/org/apache/lucene/search/LeafCollector.html
Collector receives internal, per segment ordinal ids, not _external_ ids, which 
you may expect 

> IndexSearcher.search(Query, Collector) sends duplicate documents to collector 
> when index is large enough
> 
>
> Key: LUCENE-8801
> URL: https://issues.apache.org/jira/browse/LUCENE-8801
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.4, 8.0
>Reporter: Mikhail
>Priority: Major
> Attachments: DupesTest.java
>
>
> IndexSearcher.search(Query, Collector) repeatedly sends duplicate documents 
> to collector when index is large enough. Test attached.



--
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.7 - Build # 13 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.7/13/

No tests ran.

Build Log:
[...truncated 23463 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 2465 links (2015 relative) to 3226 anchors in 246 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr-ref-guide/bare-bones-html/

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

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/package/solr-7.7.2.tgz
 into 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/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.7/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.7/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.7/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.7/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.7/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.7/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.7/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.7/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.7/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.7/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.7/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] [Updated] (LUCENE-8801) IndexSearcher.search(Query, Collector) sends duplicate documents to collector when index is large enough

[Mikhail (JIRA)]

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

Mikhail updated LUCENE-8801:

Attachment: (was: DuplicateTest.java)

> IndexSearcher.search(Query, Collector) sends duplicate documents to collector 
> when index is large enough
> 
>
> Key: LUCENE-8801
> URL: https://issues.apache.org/jira/browse/LUCENE-8801
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.4, 8.0
>Reporter: Mikhail
>Priority: Major
> Attachments: DupesTest.java
>
>
> IndexSearcher.search(Query, Collector) repeatedly sends duplicate documents 
> to collector when index is large enough. Test attached.



--
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-8801) IndexSearcher.search(Query, Collector) sends duplicate documents to collector when index is large enough

[Mikhail (JIRA)]

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

Mikhail updated LUCENE-8801:

Attachment: DupesTest.java

> IndexSearcher.search(Query, Collector) sends duplicate documents to collector 
> when index is large enough
> 
>
> Key: LUCENE-8801
> URL: https://issues.apache.org/jira/browse/LUCENE-8801
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 7.4, 8.0
>Reporter: Mikhail
>Priority: Major
> Attachments: DupesTest.java
>
>
> IndexSearcher.search(Query, Collector) repeatedly sends duplicate documents 
> to collector when index is large enough. Test attached.



--
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] (LUCENE-8801) IndexSearcher.search(Query, Collector) sends duplicate documents to collector when index is large enough

[Mikhail (JIRA)]

Mikhail created LUCENE-8801:
---

 Summary: IndexSearcher.search(Query, Collector) sends duplicate 
documents to collector when index is large enough
 Key: LUCENE-8801
 URL: https://issues.apache.org/jira/browse/LUCENE-8801
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: 8.0, 7.4
Reporter: Mikhail
 Attachments: DuplicateTest.java

IndexSearcher.search(Query, Collector) repeatedly sends duplicate documents to 
collector when index is large enough. Test attached.



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